This involves temporarily hard wiring some parts to use the global context. This isn't ideal, but it's
the only way I could figure out to make this process vaguely incremental.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75445 91177308-0d34-0410-b5e6-96231b3b80d8
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75379 91177308-0d34-0410-b5e6-96231b3b80d8
create separate recursive mutexes for each value map. The recursive-ness fixes the double-acquiring issue, which having one per ValueMap
lets us continue to maintain some concurrency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73801 91177308-0d34-0410-b5e6-96231b3b80d8
gets involved, and we end up trying to recursively acquire a writer lock. The fix for this is slightly horrible,
and involves passing a boolean "locked" parameter around in Constants.cpp, but it's better than having locked and
unlocked versions of most of the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73790 91177308-0d34-0410-b5e6-96231b3b80d8
Document those ValueMap functions that are _not_ locked, so that callers are aware that they need to do the locking themselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73628 91177308-0d34-0410-b5e6-96231b3b80d8
failures.
To support this, add some utility functions to Type to help support
vector/scalar-independent code. Change ConstantInt::get and
ConstantFP::get to support vector types, and add an overload to
ConstantInt::get that uses a static IntegerType type, for
convenience.
Introduce a new getConstant method for ScalarEvolution, to simplify
common use cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73431 91177308-0d34-0410-b5e6-96231b3b80d8
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8
type as a target independent constant expression. I confess
that I didn't check that this method works as intended (though
I did test the equivalent hand-written IR a little). But what
could possibly go wrong!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72213 91177308-0d34-0410-b5e6-96231b3b80d8
Constant, MDString and MDNode which can only be used by globals with a name
that starts with "llvm." or as arguments to a function with the same naming
restriction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68420 91177308-0d34-0410-b5e6-96231b3b80d8
unneeded bitcast is requested. This is common for frontends who just unconditionally
cast even if the target is often the right type already. THis prevents going into
getFoldedCast which switches on the opcode and does a bunch of other stuff before
doing the same opzn.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67435 91177308-0d34-0410-b5e6-96231b3b80d8
shift constant expressions, and add support for folding vector
shift constant expressions. This fixes PR3802.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@67010 91177308-0d34-0410-b5e6-96231b3b80d8
folded. Remove code that handled the case where they aren't
folded, and remove bitcode reader/writer support for them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53887 91177308-0d34-0410-b5e6-96231b3b80d8
when presented with a constant expr.
If ConstantExpr::getV[IF]Cmp to work when ConstantFoldCompareInstruction
returns an undef or constant expr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53541 91177308-0d34-0410-b5e6-96231b3b80d8
