for NSW/NUW binops to follow the pattern of exact binops. This
allows someone to use Builder.CreateAdd(x, y, "tmp", MaybeNUW);
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125270 91177308-0d34-0410-b5e6-96231b3b80d8
"this" pointer for any subclass of User, you could static_cast it to
User* and then reinterpret_cast that to Use* to get the end of the
operand list. This isn't a safe assumption in general, because the
static_cast might adjust the "this" pointer. Fixed by having these
OperandTraits classes take an extra template parameter, which is the
subclass of User. This is groundwork for PR889.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123235 91177308-0d34-0410-b5e6-96231b3b80d8
necessary to swap the operands to handle NaN and negative zero properly.
Also, reintroduce logic for checking for NaN conditions when forming
SSE min and max instructions, fixed to take into consideration NaNs and
negative zeros. This allows forming min and max instructions in more
cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97025 91177308-0d34-0410-b5e6-96231b3b80d8
getOffsetOf, and remove the comment about assuming i8 is byte-aligned,
which is no longer applicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94738 91177308-0d34-0410-b5e6-96231b3b80d8
a convention (shadowing the setter with private forwarding function) to
prevent subclasses from accidentally using it.
This exposed some bogosity in ConstantExprs, which was propaging the
opcode of the constant expr into the NUW/NSW/Exact field in the
getWithOperands/getWithOperandReplaced methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92239 91177308-0d34-0410-b5e6-96231b3b80d8
block with a blockaddress still referring to it' replace the invalid
blockaddress with a new blockaddress(@func, null) instead of a
inttoptr(1).
This changes the bitcode encoding format, and still needs codegen
support (this should produce a non-zero value, referring to the entry
block of the function would also be quite reasonable).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85678 91177308-0d34-0410-b5e6-96231b3b80d8
In the new world order, BlockAddress can have a BasicBlock operand.
This doesn't permute much, because if you have a ConstantExpr (or
anything more specific than Constant) we still know the operand has
to be a Constant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85375 91177308-0d34-0410-b5e6-96231b3b80d8
within the notional bounds of the static type of the getelementptr (which
is not the same as "inbounds") from GlobalOpt into a utility routine,
and use it in ConstantFold.cpp to check whether there are any mis-behaved
indices.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81478 91177308-0d34-0410-b5e6-96231b3b80d8
Constant uniquing tables. This allows distinct ConstantExpr objects
with the same operation and different flags.
Even though a ConstantExpr "a + b" is either always overflowing or
never overflowing (due to being a ConstantExpr), it's still necessary
to be able to represent it both with and without overflow flags at
the same time within the IR, because the safety of the flag may
depend on the context of the use. If the constant really does overflow,
it wouldn't ever be safe to use with the flag set, however the use
may be in code that is never actually executed.
This also makes it possible to merge all the flags tests into a single test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80998 91177308-0d34-0410-b5e6-96231b3b80d8
and exact flags. Because ConstantExprs are uniqued, creating an
expression with this flag causes all expressions with the same operands
to have the same flag, which may not be safe. Add, sub, mul, and sdiv
ConstantExprs are usually folded anyway, so the main interesting flag
here is inbounds, and the constant folder already knows how to set the
inbounds flag automatically in most cases, so there isn't an urgent need
for the API support.
This can be reconsidered in the future, but for now just removing these
API bits eliminates a source of potential trouble with little downside.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80959 91177308-0d34-0410-b5e6-96231b3b80d8
Use CallbackVH, instead of WeakVH, to hold MDNode elements.
Use FoldingSetNode to unique MDNodes in a context.
Use CallbackVH hooks to update context's MDNodeSet appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80868 91177308-0d34-0410-b5e6-96231b3b80d8
Use FoldingSetNode to unique MDNodes in a context.
Use CallbackVH hooks to update context's MDNodeSet appropriately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80839 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
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
true), and casts make me nervous and are verbose anyway, so here's a
ConstantInt::getSigned(Ty, int64_t) method. Just overloading
ConstantInt::get() to take an int64_t too would cause ambiguous
overload errors."
Patch by Jeffrey Yasskin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69958 91177308-0d34-0410-b5e6-96231b3b80d8
