History log of /external/llvm/lib/IR/ConstantFold.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
2c3e0051c31c3f5b2328b447eadf1cf9c4427442 06-May-2015 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master LLVM for rebase to r235153

Change-Id: I9bf53792f9fc30570e81a8d80d296c681d005ea7
(cherry picked from commit 0c7f116bb6950ef819323d855415b2f2b0aad987)
/external/llvm/lib/IR/ConstantFold.cpp
4c5e43da7792f75567b693105cc53e3f1992ad98 08-Apr-2015 Pirama Arumuga Nainar <pirama@google.com> Update aosp/master llvm for rebase to r233350

Change-Id: I07d935f8793ee8ec6b7da003f6483046594bca49
/external/llvm/lib/IR/ConstantFold.cpp
ebe69fe11e48d322045d5949c83283927a0d790b 23-Mar-2015 Stephen Hines <srhines@google.com> Update aosp/master LLVM for rebase to r230699.

Change-Id: I2b5be30509658cb8266be782de0ab24f9099f9b9
/external/llvm/lib/IR/ConstantFold.cpp
37ed9c199ca639565f6ce88105f9e39e898d82d0 01-Dec-2014 Stephen Hines <srhines@google.com> Update aosp/master LLVM for rebase to r222494.

Change-Id: Ic787f5e0124df789bd26f3f24680f45e678eef2d
/external/llvm/lib/IR/ConstantFold.cpp
c6a4f5e819217e1e12c458aed8e7b122e23a3a58 21-Jul-2014 Stephen Hines <srhines@google.com> Update LLVM for rebase to r212749.

Includes a cherry-pick of:
r212948 - fixes a small issue with atomic calls

Change-Id: Ib97bd980b59f18142a69506400911a6009d9df18
/external/llvm/lib/IR/ConstantFold.cpp
dce4a407a24b04eebc6a376f8e62b41aaa7b071f 29-May-2014 Stephen Hines <srhines@google.com> Update LLVM for 3.5 rebase (r209712).

Change-Id: I149556c940fb7dc92d075273c87ff584f400941f
/external/llvm/lib/IR/ConstantFold.cpp
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/lib/IR/ConstantFold.cpp
59d3ae6cdc4316ad338cd848251f33a236ccb36c 15-Nov-2013 Matt Arsenault <Matthew.Arsenault@amd.com> Add addrspacecast instruction.

Patch by Michele Scandale!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194760 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
b831e13387c88c39f382db3f76e85433f1978e7f 10-Nov-2013 David Majnemer <david.majnemer@gmail.com> IR: Refactor GEP range checks, reuse them for other parts of folding


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194341 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
f9c692cfeb9a73bad531f86d9f103e67d3d0e162 07-Nov-2013 David Majnemer <david.majnemer@gmail.com> IR: Properly canonicalize PointerType in ConstantExpr GEPs

No additional test was needed, Other/constant-fold-gep.ll detects this
just fine.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
0ab20588523b59a65a4a29d47184a41443fa9337 07-Nov-2013 David Majnemer <david.majnemer@gmail.com> IR: Do not canonicalize constant GEPs into an out-of-bounds array access

Summary:
Consider a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0)

If we proceeded to GEP the aforementioned object by 8, would form a GEP of:
i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8)

Note that we would go through the first array member, causing an
out-of-bounds accesses. This is problematic because we might get fooled
if we are trying to evaluate loads using this GEP, for example, based
off of an object with a constant initializer where the array is zero.

This fixes PR17732.

Reviewers: nicholas, chandlerc, void

Reviewed By: void

CC: llvm-commits, echristo, void, aemerson

Differential Revision: http://llvm-reviews.chandlerc.com/D2093

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194220 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
3181f5900ff5d9800c38284c7d3427cb6e306c9a 31-Jul-2013 Matt Arsenault <Matthew.Arsenault@amd.com> Respect address space sizes in isEliminableCastPair.

This avoids constant folding bitcast/ptrtoint/inttoptr combinations
that have illegal bitcasts between differently sized address spaces.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187455 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
80c070493d657a4bcc6eca5627c28d659d3330d8 30-Jun-2013 Benjamin Kramer <benny.kra@googlemail.com> ConstantFold: Check that truncating the other side is safe under a sext when trying to remove a sext from a compare.

Fixes PR16462.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185284 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
8df7c39976890d94198d835e032848a374fec158 27-Feb-2013 Meador Inge <meadori@codesourcery.com> IR: Don't constant fold GEP bitcasts between different address spaces

PR15262 reported a bug where the following instruction:

i8 getelementptr inbounds i8* bitcast ([4 x i8] addrspace(12)* @buf to i8*),
i32 2

was getting folded into:

addrspace(12)* getelementptr inbounds ([4 x i8] addrspace(12)* @buf, i32 0,
i32 2)

This caused instcombine to crash because the original instruction and
the folded instruction have different types. The issue was fixed by
disallowing bitcasts between different address spaces to be folded away.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176156 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
a175396816a9b28835acfe2cd07250881f1fee6c 19-Feb-2013 Nadav Rotem <nrotem@apple.com> Fix a bug that was found by the clang static analyzer. The var "AT" is null so we cant deref it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175550 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
d363ae52995059906d99f7588f47bf891e7db485 31-Jan-2013 Dan Gohman <dan433584@gmail.com> Fix ConstantFold's folding of icmp instructions to recognize that,
for example, a one-past-the-end pointer from one global variable may
be equal to the base pointer of another global variable.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173995 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
0a29cb045444c13160e90fe7942a9d7c720185ed 22-Jan-2013 Tim Northover <Tim.Northover@arm.com> Make APFloat constructor require explicit semantics.

Previously we tried to infer it from the bit width size, with an added
IsIEEE argument for the PPC/IEEE 128-bit case, which had a default
value. This default value allowed bugs to creep in, where it was
inappropriate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173138 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
0b8c9a80f20772c3793201ab5b251d3520b9cea3 02-Jan-2013 Chandler Carruth <chandlerc@gmail.com> Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp
c2c50cdcdc19a1bca993c06d13d8cdca87083ce4 02-Jan-2013 Chandler Carruth <chandlerc@gmail.com> Rename VMCore directory to IR.

Aside from moving the actual files, this patch only updates the build
system and the source file comments under lib/... that are relevant.

I'll be updating other docs and other files in smaller subsequnet
commits.

While I've tried to test this, but it is entirely possible that there
will still be some build system fallout.

Also, note that I've not changed the library name itself: libLLVMCore.a
is still the library name. I'd be interested in others' opinions about
whether we should rename this as well (I think we should, just not sure
what it might break)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171359 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/lib/IR/ConstantFold.cpp