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
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
This may be used as the second IRBuilder template
parameter, the idea being that people learning LLVM
may find it helpful (several people asked on IRC
if it was possible to turn off constant folding
because it made it hard for them to see what was
going on). Compiles, but otherwise completely
untested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54698 91177308-0d34-0410-b5e6-96231b3b80d8
folding policies with IRBuilder. The default,
provided by ConstantFolder, is to do minimal
folding like now: what ConstantExpr provides.
An alternative is to use TargetFolder, which
uses target information to fold constants more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54640 91177308-0d34-0410-b5e6-96231b3b80d8
