llvm/lib/Transforms/InstCombine, branch release_32http://llvm.orghttps://git.amat.us/llvm/atom/lib/Transforms/InstCombine?h=release_322012-11-26T16:52:27ZMerging r168196: into the 3.2 release branch.2012-11-26T16:52:27ZPawel Wodnickipawel@32bitmicro.com2012-11-26T16:52:27Zurn:sha1:bc69dc1d880792c0c2bbea189c3dbb2c39505391
Make this easier to understand, as suggested by Chandler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168594 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r168354: into 3.2 release branch2012-11-22T06:08:33ZPawel Wodnickipawel@32bitmicro.com2012-11-22T06:08:33Zurn:sha1:d11161f404bf670f4f4b3b993bdad6894fbfd5ba
Make the AttrListPtr object a part of the LLVMContext.
When code deletes the context, the AttributeImpls that the AttrListPtr points to
are now invalid. Therefore, instead of keeping a separate managed static for the
AttrListPtrs that's reference counted, move it into the LLVMContext and delete
it when deleting the AttributeImpls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168486 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r168280: into 3.2 release branch.2012-11-22T00:43:18ZPawel Wodnickipawel@32bitmicro.com2012-11-22T00:43:18Zurn:sha1:ddf07067bc7ec9897a17352c2db23fb4d1a55db4
Don't try to calculate the alignment of an unsigned type. Fixes PR14371!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168480 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting 1684572012-11-21T22:21:40ZPawel Wodnickipawel@32bitmicro.com2012-11-21T22:21:40Zurn:sha1:3e2cbf9d08ffd6f26302c19fdc7997e441c741e9
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168465 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r168354, r168355 and r168379 into the 3.2 release branch.2012-11-21T20:30:37ZPawel Wodnickipawel@32bitmicro.com2012-11-21T20:30:37Zurn:sha1:7022c651cab8a4e3e310e024a2028eb9fa5b482e
Set of Attributes patches.
Merging r168354:
Make the AttrListPtr object a part of the LLVMContext.
When code deletes the context, the AttributeImpls that the AttrListPtr points to
are now invalid. Therefore, instead of keeping a separate managed static for the
AttrListPtrs that's reference counted, move it into the LLVMContext and delete
it when deleting the AttributeImpls.
Merging r168355:
Merging r168379
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168457 91177308-0d34-0410-b5e6-96231b3b80d8
Merging r168181: into 3.2 release branch.2012-11-21T19:01:53ZPawel Wodnickipawel@32bitmicro.com2012-11-21T19:01:53Zurn:sha1:07d7748544abaaf97123233804a194478ed020b3
Fix PR14361: wrong simplification of A+B==B+A. You may think that the old logic
replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was. There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_32@168447 91177308-0d34-0410-b5e6-96231b3b80d8
Add method for replacing instructions to LibCallSimplifier2012-11-11T03:51:43ZMeador Ingemeadori@codesourcery.com2012-11-11T03:51:43Zurn:sha1:b69bf6be1b042a5f06a623fc546107fc6d9f46c4
In some cases the library call simplifier may need to replace instructions
other than the library call being simplified. In those cases it may be
necessary for clients of the simplifier to override how the replacements
are actually done. As such, a new overrideable method for replacing
instructions was added to LibCallSimplifier.
A new subclass of LibCallSimplifier is also defined which overrides
the instruction replacement method. This is because the instruction
combiner defines its own replacement method which updates the worklist
when instructions are replaced.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167681 91177308-0d34-0410-b5e6-96231b3b80d8
Generalize the transform that boosts GEP indices to the size of a pointer to2012-11-03T11:44:17ZDuncan Sandsbaldrick@free.fr2012-11-03T11:44:17Zurn:sha1:c5b969a0194aa3e3d8170ddd38ab3cb8c9f3113c
also do it for vectors of pointers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167354 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the majority of the next patch in the address space series:2012-11-01T09:14:31ZChandler Carruthchandlerc@gmail.com2012-11-01T09:14:31Zurn:sha1:426c2bf5cdd2173e4a33aea8cb92cf684a724f4b
r165941: Resubmit the changes to llvm core to update the functions to
support different pointer sizes on a per address space basis.
Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.
However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.
In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.
In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.
This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167222 91177308-0d34-0410-b5e6-96231b3b80d8
Revert the series of commits starting with r166578 which introduced the2012-11-01T08:07:29ZChandler Carruthchandlerc@gmail.com2012-11-01T08:07:29Zurn:sha1:ece6c6bb6329748b92403c06ac87f45c43485911
getIntPtrType support for multiple address spaces via a pointer type,
and also introduced a crasher bug in the constant folder reported in
PR14233.
These commits also contained several problems that should really be
addressed before they are re-committed. I have avoided reverting various
cleanups to the DataLayout APIs that are reasonable to have moving
forward in order to reduce the amount of churn, and minimize the number
of commits that were reverted. I've also manually updated merge
conflicts and manually arranged for the getIntPtrType function to stay
in DataLayout and to be defined in a plausible way after this revert.
Thanks to Duncan for working through this exact strategy with me, and
Nick Lewycky for tracking down the really annoying crasher this
triggered. (Test case to follow in its own commit.)
After discussing with Duncan extensively, and based on a note from
Micah, I'm going to continue to back out some more of the more
problematic patches in this series in order to ensure we go into the
LLVM 3.2 branch with a reasonable story here. I'll send a note to
llvmdev explaining what's going on and why.
Summary of reverted revisions:
r166634: Fix a compiler warning with an unused variable.
r166607: Add some cleanup to the DataLayout changes requested by
Chandler.
r166596: Revert "Back out r166591, not sure why this made it through
since I cancelled the command. Bleh, sorry about this!
r166591: Delete a directory that wasn't supposed to be checked in yet.
r166578: Add in support for getIntPtrType to get the pointer type based
on the address space.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167221 91177308-0d34-0410-b5e6-96231b3b80d8