This avoids constant folding bitcast/ptrtoint/inttoptr combinations
that have illegal bitcasts between differently sized address spaces.
llvm-svn: 187455
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.
llvm-svn: 176156
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.
llvm-svn: 173138
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.
llvm-svn: 171366
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)
llvm-svn: 171359
