there.
This changes the interpreter to use libffi. After this patch, the interpreter
will barely be able to call any external functions if built on a system without
libffi installed (just enough to pass 'make check' really). But with libffi,
we can now call any function that isn't variadic or taking a struct or vector
parameter (but pointer to struct is fine). Patch by Alexei Svitkine!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63723 91177308-0d34-0410-b5e6-96231b3b80d8
turn icmp eq a+x, b+x into icmp eq a, b if a+x or b+x has other uses. This
may have been increasing register pressure leading to the bzip2 slowdown.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63487 91177308-0d34-0410-b5e6-96231b3b80d8
This requires a rebuild of 'configure' itself. I will be committing that next, but
built with the wrong version of autoconf. Somebody who has the right one, please update
it.
As a side-note, because of the way autoconf works, all built tools will link against
libffi, not just lli. If you know how to fix this, please let me know ...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62553 91177308-0d34-0410-b5e6-96231b3b80d8
The way this worked before was to test APInt by running
"lli -force-interpreter=true" knowing the lli uses APInt under the hood to
store its values. Now, we test APInt directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62514 91177308-0d34-0410-b5e6-96231b3b80d8
putc, puts, perror, vscanf and vsscanf from getting annotations.
Add annotations for eight printf functions, memalign, pread and pwrite.
On Linux, llvm-gcc sometimes renames strdup, getc, putc, strtok_r, scanf and
sscanf. Match the alternate function names.
Fix a crash annotating opendir.
Don't mark fsetpos's second parameter as nocapture. It's supposed to be
captured.
Do mark fopen's path and mode strings as nocapture. Mark ferror as readonly,
but not fileno which may set errno.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@62456 91177308-0d34-0410-b5e6-96231b3b80d8
Finalization occurs after all the FunctionPasses in the group have run, which
is clearly not what we want.
This also means that we have to make sure that we apply the right param
attributes when creating a new function.
Also, add a missed optimization: strdup and strndup. NoCapture and
NoAlias return!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61658 91177308-0d34-0410-b5e6-96231b3b80d8
Clean up some of the existing code by making it use hasFnAttr/addFnAttr
and round it off by creating removeFnAttr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61627 91177308-0d34-0410-b5e6-96231b3b80d8
reason. Two functions which mutually require each other to be nocapture
are not currently supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61553 91177308-0d34-0410-b5e6-96231b3b80d8
functions that don't write can't leak a pointer except through
the return value, so a void readonly function is implicitly nocapture.
Test these, and add a test that verifies that f1 calling f2 with an
otherwise dead pointer gets both of them marked nocapture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61552 91177308-0d34-0410-b5e6-96231b3b80d8
The problematic part of this patch is that we were out of attribute bits,
requiring some fancy bit hacking to make it fit (by shrinking alignment)
without breaking existing users or the file format.
This change will require users to rebuild llvm-gcc to match llvm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61239 91177308-0d34-0410-b5e6-96231b3b80d8
alignment attribute such that 0 means unaligned.
This will probably require a rebuild of llvm-gcc because of the change to
Attributes.h. If you see many test failures on "make check", please rebuild
your llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61030 91177308-0d34-0410-b5e6-96231b3b80d8
callee will not introduce any new aliases of that pointer.
The attributes had all bits allocated already, so I decided to collapse
alignment. Alignment was previously stored as a 16-bit integer from bits 16 to
32 of the attribute, but it was required to be a power of 2. Now it's stored in
log2 encoded form in five bits from 16 to 21. That gives us 11 more bits of
space.
You may have already noticed that you only need four bits to encode a 16-bit
power of two, so why five bits? Because the AsmParser accepted 32-bit
alignments, even though we couldn't store them (they were silently discarded).
Now we can store them in memory, but not in the bitcode.
The bitcode format was already storing these as 64-bit VBR integers. So, the
bitcode format stays the same, keeping the alignment values stored as 16 bit
raw values. There's some hideous code in the reader and writer that deals with
this, waiting to be ripped out the moment we run out of bits again and have to
replace the parameter attributes table encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61019 91177308-0d34-0410-b5e6-96231b3b80d8
Despite changing the order of evaluation, this doesn't actually change the
meaning of the statement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@60177 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
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
* merge two weak functions by making them both alias a third non-weak fn
* don't reimplement CallSite::hasArgument
* whitelist the safe linkage types
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58568 91177308-0d34-0410-b5e6-96231b3b80d8
This triggers only 60 times in llvm-test (look at .llvm.bc, not .linked.rbc)
and so it probably wont be turned on by default. Also, may of those are likely
to go away when PR2973 is fixed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58557 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
be folded. Instead, fail to fold the entire vector.
We could also return a vector with some elements folded and some not. If anyone
thinks that's a better approach, please speak up!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@55689 91177308-0d34-0410-b5e6-96231b3b80d8
Nick Lewycky