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
|