but it doesn't make any sense at all.
Also make the method const, private, and fit in 80 cols while we're at it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60215 91177308-0d34-0410-b5e6-96231b3b80d8
value. It must now be as if the pointer were allocated and has not escaped to
the caller. Thanks to Dan Gohman for pointing out the error in the original
and helping devise this definition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59940 91177308-0d34-0410-b5e6-96231b3b80d8
indicate functions that allocate, such as operator new, or list::insert. The
actual definition is slightly less strict (for now).
No changes to the bitcode reader/writer, asm printer or verifier were needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59934 91177308-0d34-0410-b5e6-96231b3b80d8
g++ -m32 -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wmissing-format-attribute -fno-common -mdynamic-no-pic -DHAVE_CONFIG_H -Wno-unused -DTARGET_NAME=\"i386-apple-darwin9.5.0\" -I. -I. -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/. -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/include -DENABLE_LLVM -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/../llvm.src/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I. -I. -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/. -I../../llvm-gcc.src/gcc/../include -I./../intl -I../../llvm-gcc.src/gcc/../libcpp/include -I../../llvm-gcc.src/gcc/../libdecnumber -I../libdecnumber -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.obj/include -I/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/include ../../llvm-gcc.src/gcc/llvm-types.cpp -o llvm-types.o
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemCpy(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1496: error: 'memcpy_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1496: error: 'memcpy_i64' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemMove(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1512: error: 'memmove_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1512: error: 'memmove_i64' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp: In member function 'void TreeToLLVM::EmitMemSet(llvm::Value*, llvm::Value*, llvm::Value*, unsigned int)':
../../llvm-gcc.src/gcc/llvm-convert.cpp:1528: error: 'memset_i32' is not a member of 'llvm::Intrinsic'
../../llvm-gcc.src/gcc/llvm-convert.cpp:1528: error: 'memset_i64' is not a member of 'llvm::Intrinsic'
make[3]: *** [llvm-convert.o] Error 1
make[3]: *** Waiting for unfinished jobs....
rm fsf-funding.pod gcov.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59809 91177308-0d34-0410-b5e6-96231b3b80d8
Use it to safely handle less-than-or-equals-to exit conditions in loops. These
also occur when the loop exit branch is exit on true because SCEV inverses the
icmp predicate.
Use it again to handle non-zero strides, but only with an unsigned comparison
in the exit condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59528 91177308-0d34-0410-b5e6-96231b3b80d8
If this patch causes a performance regression for anyone, please let me know,
and it can be fixed in a different way with much more effort.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59384 91177308-0d34-0410-b5e6-96231b3b80d8
implementation detail of DIFactory anyway, and this allows it to avoid
recomputing the same type over and over.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58960 91177308-0d34-0410-b5e6-96231b3b80d8
information. This logically replaces the "Desc" classes in
MachineModuleInfo. Nice features of these classes are that they:
1. Are much more efficient than MMI because they don't create a
temporary parallel data structure for debug info that has to be
'serialized' and 'deserialized' into/out of the module.
2. These provide a much cleaner abstraction for debug info than
MMI, which will make it easier to change the implementation in
the future (to be MDNode-based).
3. These are much easier to use than the MMI interfaces, requiring
a lot less code in the front-ends.
4. These can be used to both create (for frontends) and read (for
codegen) debug information. DebugInfoBuilder can only be used
to create the nodes.
So far, this is implemented just enough to support the debug info
generation needs of clang. This can and should be extended to
support the full set of debug info constructs, and we should switch
llvm-gcc and llc over to using this in the near future.
This code also has a ton of FIXMEs in it, because the way we
currently represent debug info in LLVM IR is basically insane in a
variety of details. This sort of issue should be fixed when we
eventually reimplement debug info on top of MDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58954 91177308-0d34-0410-b5e6-96231b3b80d8
returned by BinomialCoefficient and don't try to operate with them. This
replaces the previous fix for PR2857.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57431 91177308-0d34-0410-b5e6-96231b3b80d8
pointer bitcasts and GEP's", and centralize the
logic in Value::getUnderlyingObject. The
difference with stripPointerCasts is that
stripPointerCasts only strips GEPs if all
indices are zero, while getUnderlyingObject
strips GEPs no matter what the indices are.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56922 91177308-0d34-0410-b5e6-96231b3b80d8
- Recognize expressions like "x > -1 ? x : 0" as min/max and turn them
into expressions like "x < 0 ? 0 : x", which is easily recognizable
as a min/max operation.
- Refrain from folding expression like "y/2 < 1" to "y < 2" when the
comparison is being used as part of a min or max idiom, like
"y/2 < 1 ? 1 : y/2". In that case, the division has another use, so
folding doesn't eliminate it, and obfuscates the min/max, making it
harder to recognize as a min/max operation.
These benefit ScalarEvolution, CodeGen, and anything else that wants to
recognize integer min and max.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56246 91177308-0d34-0410-b5e6-96231b3b80d8
its callers to emit a space character before calling it when a
space is needed.
This fixes several spurious whitespace issues in
ScalarEvolution's debug dumps. See the test changes for
examples.
This also fixes odd space-after-tab indentation in the output
for switch statements, and changes calls from being printed like
this:
call void @foo( i32 %x )
to this:
call void @foo(i32 %x)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56196 91177308-0d34-0410-b5e6-96231b3b80d8
when a readonly declaration is called, set a
flag. This is faster and uses less memory.
In theory it is less accurate, because before
only those internal globals that were read
by someone were being marked "Ref", but now
all are. But in practice, thanks to other
passes, all internal globals of the kind
considered here will be both read and stored
to: those only read will have been turned
into constants, and those only stored to will
have been deleted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@56143 91177308-0d34-0410-b5e6-96231b3b80d8
(1) code left over from the days of ConstantPointerRef:
if a use of a function is a GlobalValue then that is
not considered a reason to add an edge from the external
node, even though the use may be as an initializer for
an externally visible global! There might be some point
to this behaviour when the use is by an alias (though the
code predated aliases by some centuries), but I think
PR2782 is a better way of handling that. (2) If function
F calls function G, and also G is a parameter to the
call, then an F->G edge is not added to the callgraph.
While this doesn't seem to matter much, adding such an
edge makes the callgraph more regular.
In addition, the new code should be faster as well as
simpler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55987 91177308-0d34-0410-b5e6-96231b3b80d8
call (thus changing the call site) it didn't
inform the callgraph about this. But the
call site does matter - as shown by the testcase,
the callgraph become invalid after the inliner
ran (with an edge between two functions simply
missing), resulting in wrong deductions by
GlobalsModRef.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55872 91177308-0d34-0410-b5e6-96231b3b80d8
because it does not maintain a correct list
of callsites. I discovered (see following
commit) that the inliner will create a wrong
callgraph if it is fed a callgraph with
correct edges but incorrect callsites. These
were created by Prune-EH, and while it wasn't
done via removeCallEdgeTo, it could have been
done via removeCallEdgeTo, which is an accident
waiting to happen. Use removeCallEdgeFor
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55859 91177308-0d34-0410-b5e6-96231b3b80d8
analysis would bail out without removing function
records for other members of the SCC (which may exist
if those functions read or wrote global variables).
Since these are initialized to "readnone", this
resulted in incorrect alias analysis results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55714 91177308-0d34-0410-b5e6-96231b3b80d8
doesNotAccessMemory, check doesNotAccessMemory
first, since otherwise functions may be
marked readonly rather than readnone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55697 91177308-0d34-0410-b5e6-96231b3b80d8
callgraph, when one member of a SCC calls another
then the analysis would drop to mod-ref because
there is (usually) no function info for the callee
yet; fix this. Teach the analysis about function
attributes, in particular the readonly attribute
(which requires being careful about globals).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55696 91177308-0d34-0410-b5e6-96231b3b80d8
use raw_ostream instead of std::ostream. Among other goodness,
this speeds up llvm-dis of kc++ with a release build from 0.85s
to 0.49s (88% faster).
Other interesting changes:
1) This makes Value::print be non-virtual.
2) AP[S]Int and ConstantRange can no longer print to ostream directly,
use raw_ostream instead.
3) This fixes a bug in raw_os_ostream where it didn't flush itself
when destroyed.
4) This adds a new SDNode::print method, instead of only allowing "dump".
A lot of APIs have both std::ostream and raw_ostream versions, it would
be useful to go through and systematically anihilate the std::ostream
versions.
This passes dejagnu, but there may be minor fallout, plz let me know if
so and I'll fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55263 91177308-0d34-0410-b5e6-96231b3b80d8
can have a non-negative result; for example, -16%16 is 0. Also,
clarify the related comments. This fixes PR2670.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54767 91177308-0d34-0410-b5e6-96231b3b80d8
continue past the first conditional branch when looking for a
relevant test. This helps it avoid using MAX expressions in
loop trip counts in more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54697 91177308-0d34-0410-b5e6-96231b3b80d8
type lattice value for an Argument*, giving clients the opportunity to
use something other than Top for it if they choose to."
Patch by John McCall!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54589 91177308-0d34-0410-b5e6-96231b3b80d8
version uses a new algorithm for evaluating the binomial coefficients
which is significantly more efficient for AddRecs of more than 2 terms
(see the comments in the code for details on how the algorithm works).
It also fixes some bugs: it removes the arbitrary length restriction for
AddRecs, it fixes the silent generation of incorrect code for AddRecs
which require a wide calculation width, and it fixes an issue where we
were incorrectly truncating the iteration count too far when evaluating
an AddRec expression narrower than the induction variable.
There are still a few related issues I know of: I think there's
still an issue with the SCEVExpander expansion of AddRec in terms of
the width of the induction variable used. The hack to avoid generating
too-wide integers shouldn't be necessary; instead, the callers should be
considering the cost of the expansion before expanding it (in addition
to not expanding too-wide integers, we might not want to expand
expressions that are really expensive, especially when optimizing for
size; calculating an length-17 32-bit AddRec currently generates about 250
instructions of straight-line code on X86). Also, for long 32-bit
AddRecs on X86, CodeGen really sucks at scheduling the code. I'm planning on
filing follow-up PRs for these issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54332 91177308-0d34-0410-b5e6-96231b3b80d8
time applying to the implicit comparison in smin expressions. The
correct way to transform an inequality into the opposite
inequality, either signed or unsigned, is with a not expression.
I looked through the SCEV code, and I don't think there are any more
occurrences of this issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54194 91177308-0d34-0410-b5e6-96231b3b80d8
SGT exit condition. Essentially, the correct way to flip an inequality
in 2's complement is the not operator, not the negation operator.
That said, the difference only affects cases involving INT_MIN.
Also, enhance the pre-test search logic to be a bit smarter about
inequalities flipped with a not operator, so it can eliminate the smax
from the iteration count for simple loops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54184 91177308-0d34-0410-b5e6-96231b3b80d8
circumstances we could end up remapping a dependee to the same instruction
that we're trying to remove. Handle this properly by just falling back to
a conservative solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@54132 91177308-0d34-0410-b5e6-96231b3b80d8
bail after 256-bits to avoid producing code that the backends can't handle.
Previously, we capped it at 64-bits, preferring to miscompile in those cases.
This change also reverts much of r52248 because the invariants the code was
expecting are now being met.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@53812 91177308-0d34-0410-b5e6-96231b3b80d8
Move GetConstantStringInfo to lib/Analysis. Remove
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
This unbreaks llvm-gcc bootstrap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52884 91177308-0d34-0410-b5e6-96231b3b80d8
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52748 91177308-0d34-0410-b5e6-96231b3b80d8
inserting extractvalues. In particular, this prevents the insertion of
extractvalues that can't be folded away later. Also add an example of when this
stuff is needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52328 91177308-0d34-0410-b5e6-96231b3b80d8
I'm at it, rename it to FindInsertedValue.
The only functional change is that newly created instructions are no longer
added to instcombine's worklist, but that is not really necessary anyway (and
I'll commit some improvements next that will completely remove the need).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52315 91177308-0d34-0410-b5e6-96231b3b80d8
pointer derived from a local allocation, if the local allocation
never escapes, the pointers can't alias. This implements PR2436
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52301 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes several minor bugs (such as returning noalias
for comparisons between external weak functions an null) but
is mostly a cleanup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52299 91177308-0d34-0410-b5e6-96231b3b80d8
take into account the instrucion pointed by InsertPt. Thanks to it,
returning the new value of InsertPt to the InsertBinop() caller can be
avoided. The bug was, actually, in visitAddRecExpr() method which wasn't
correctly handling changes of InsertPt. There shouldn't be any
performance regression, as -gvn pass (run after -indvars) removes any
redundant binops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52291 91177308-0d34-0410-b5e6-96231b3b80d8
Add a safety measure. It isn't safe to assume in ScalarEvolutionExpander that
all loops are in canonical form (but it should be safe for loops that have
AddRecs).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52275 91177308-0d34-0410-b5e6-96231b3b80d8
with code that was expecting different bit widths for different values.
Make getTruncateOrZeroExtend a method on ScalarEvolution, and use it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52248 91177308-0d34-0410-b5e6-96231b3b80d8
is longer than the second one) should stop after finding one. Added break
instruction guarantees it. It also changes difference between offsets to
absolute value of this difference in the condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51875 91177308-0d34-0410-b5e6-96231b3b80d8
out of instcombine into a new file in libanalysis. This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51863 91177308-0d34-0410-b5e6-96231b3b80d8
Analysis/ConstantFolding to fold ConstantExpr's, then make instcombine use it
to try to use targetdata to fold constant expressions on void instructions.
Also extend the icmp(inttoptr, inttoptr) folding to handle the case where
int size != ptr size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51559 91177308-0d34-0410-b5e6-96231b3b80d8
several things that were neither in an anonymous namespace nor static
but not intended to be global.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51017 91177308-0d34-0410-b5e6-96231b3b80d8
SCCP like sparse lattice analysis with relative ease. Just pick your
lattice function and implement the transfer function and you're good.
Just make sure you don't break monotonicity ;-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50961 91177308-0d34-0410-b5e6-96231b3b80d8
by an instance of LibCallInfo to provide mod/ref info of
standard library functions. This is powerful enough to
say that 'sqrt' is readonly except that it modifies errno,
or that "printf doesn't store to memory unless the %n
constraint is present" etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50827 91177308-0d34-0410-b5e6-96231b3b80d8
Currently is sufficient to describe mod/ref behavior but will hopefully
eventually be extended for other purposes.
This isn't used by anything yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50820 91177308-0d34-0410-b5e6-96231b3b80d8
manually performing the comparison. This allows the special
case to work correctly even in the case where someone is
experimenting with a different comparison function :-).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49670 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49277 91177308-0d34-0410-b5e6-96231b3b80d8
Parse reversed smax and umax as smin and umin and express them with negative
or binary-not SCEVs (which are really just subtract under the hood).
Parse 'xor %x, -1' as (-1 - %x).
Remove dead code (ConstantInt::get always returns a ConstantInt).
Don't use getIntegerSCEV(-1, Ty). The first value is an int, then it gets
passed into a uint64_t. Instead, create the -1 directly from
ConstantInt::getAllOnesValue().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47360 91177308-0d34-0410-b5e6-96231b3b80d8
Also, noalias arguments are be considered "like" stack allocated ones for this purpose, because
the only way they can be modref'ed is if they escape somewhere in the current function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47247 91177308-0d34-0410-b5e6-96231b3b80d8
variable (with step 1) and m is its final value. Then, the correct trip
count is SMAX(m,n)-n. Previously, we used SMAX(0,m-n), but m-n may
overflow and can't in general be interpreted as signed.
Patch by Nick Lewycky.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47007 91177308-0d34-0410-b5e6-96231b3b80d8
to the RHS. This simple change allows to compute loop iteration count
for loops with condition similar to the one in the testcase (which seems
to be quite common).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46959 91177308-0d34-0410-b5e6-96231b3b80d8
arbitrary iteration.
The patch:
1) changes SCEVSDivExpr into SCEVUDivExpr,
2) replaces PartialFact() function with BinomialCoefficient(); the
computations (essentially, the division) in BinomialCoefficient() are
performed with the apprioprate bitwidth necessary to avoid overflow;
unsigned division is used instead of the signed one.
Computations in BinomialCoefficient() require support from the code
generator for APInts. Currently, we use a hack rounding up the
neccessary bitwidth to the nearest power of 2. The hack is easy to turn
off in future.
One remaining issue: we assume the divisor of the binomial coefficient
formula can be computed accurately using 16 bits. It means we can handle
AddRecs of length up to 9. In future, we should use APInts to evaluate
the divisor.
Thanks to Nicholas for cooperation!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46955 91177308-0d34-0410-b5e6-96231b3b80d8
can't be aliased to other known objects. This allows us to know that byval
pointer args don't alias globals, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46315 91177308-0d34-0410-b5e6-96231b3b80d8
and readnone for functions with bodies because it
broke llvm-gcc-4.2 bootstrap. It turns out that,
because of LLVM's array_ref hack, gcc was computing
pure/const attributes wrong (now fixed by turning
off the gcc ipa-pure-const pass).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44937 91177308-0d34-0410-b5e6-96231b3b80d8
Changes from me implementing different way of representing points-to anything.
Changes from me that improve slightly on LCD.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44895 91177308-0d34-0410-b5e6-96231b3b80d8
Reimplement the xform in Analysis/ConstantFolding.cpp where we can use
targetdata to validate that it is safe. While I'm in there, fix some const
correctness issues and generalize the interface to the "operand folder".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44817 91177308-0d34-0410-b5e6-96231b3b80d8
not yet clear why, but in the meantime work around the
problem by making less use of readnone/readonly info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44626 91177308-0d34-0410-b5e6-96231b3b80d8
throw exceptions", just mark intrinsics with the nounwind
attribute. Likewise, mark intrinsics as readnone/readonly
and get rid of special aliasing logic (which didn't use
anything more than this anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44544 91177308-0d34-0410-b5e6-96231b3b80d8
into alias analysis. This meant updating the API
which now has versions of the getModRefBehavior,
doesNotAccessMemory and onlyReadsMemory methods
which take a callsite parameter. These should be
used unless the callsite is not known, since in
general they can do a better job than the versions
that take a function. Also, users should no longer
call the version of getModRefBehavior that takes
both a function and a callsite. To reduce the
chance of misuse it is now protected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44487 91177308-0d34-0410-b5e6-96231b3b80d8
the function type, instead they belong to functions
and function calls. This is an updated and slightly
corrected version of Reid Spencer's original patch.
The only known problem is that auto-upgrading of
bitcode files doesn't seem to work properly (see
test/Bitcode/AutoUpgradeIntrinsics.ll). Hopefully
a bitcode guru (who might that be? :) ) will fix it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44359 91177308-0d34-0410-b5e6-96231b3b80d8