booleans. This gives a better indication of what the "addReg()" is
doing. Remembering what all of those booleans mean isn't easy, especially if you
aren't spending all of your time in that code.
I took Jakob's suggestion and made it illegal to pass in "true" for the
flag. This should hopefully prevent any unintended misuse of this (by reverting
to the old way of using addReg()).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71722 91177308-0d34-0410-b5e6-96231b3b80d8
belonged. The variable declaration stuff wasn't happy with it where it
was. Sorry that the testcase is so big. Bugpoint wasn't able to reduce it
successfully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71714 91177308-0d34-0410-b5e6-96231b3b80d8
is not known to be nothrow. This allows readnone/readonly functions
to be deleted even if we don't know whether the callee can throw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71676 91177308-0d34-0410-b5e6-96231b3b80d8
IVUsers.cpp: In member function ‘bool llvm::IVUsers::AddUsersIfInteresting(llvm::Instruction*)’:
IVUsers.cpp:221: warning: ‘isSigned’ may be used uninitialized in this function
with gcc-4.3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71654 91177308-0d34-0410-b5e6-96231b3b80d8
getNoopOrSignExtend, and getTruncateOrNoop. These are similar
to getTruncateOrZeroExtend etc., except that they assert that
the conversion is either not widening or narrowing, as
appropriate. These will be used in some upcoming fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71632 91177308-0d34-0410-b5e6-96231b3b80d8
without one. Use it where we were using abs on
int64_t objects.
(I strongly suspect the casts to unsigned in the
fragments in LoopStrengthReduce are not doing whatever
the original intent was, but the obvious change to
uint64_t doesn't work. Maybe later.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71612 91177308-0d34-0410-b5e6-96231b3b80d8
a supporting preliminary patch for GCC-compatible SjLJ exception handling. Note that these intrinsics are not designed to be invoked directly by the user, but
rather used by the front-end as target hooks for exception handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71610 91177308-0d34-0410-b5e6-96231b3b80d8
- moved shrink wrapping code from PrologEpilogInserter.cpp to
new file ShrinkWrapping.cpp.
- moved PEI pass definition into new shared header PEI.h.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71588 91177308-0d34-0410-b5e6-96231b3b80d8
- This matches the normal dependency generation code.
- This also fixes the problem that when building a normal and bitcode
archive from the same source, the dependency files would overwrite
one another. Which was bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71542 91177308-0d34-0410-b5e6-96231b3b80d8
possible to build both a .a and a .bca.
- My understanding is no one else is using this stuff, please let me
know if I am wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71539 91177308-0d34-0410-b5e6-96231b3b80d8
after finding the (unique) layout predecessor. Sometimes a block may be listed
more than once, and processing it more than once in this loop can lead to
inconsistent values for FtTBB/FtFBB, since the AnalyzeBranch method does not
clear these values. There's no point in continuing the loop regardless.
The testcase for this is reduced from the 2003-05-02-DependentPHI SingleSource
test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@71536 91177308-0d34-0410-b5e6-96231b3b80d8
