For functions which are known to return a specific argument, pointer-comparison
folding can look through the function calls as part of its analysis.
Differential Revision: http://reviews.llvm.org/D9387
llvm-svn: 275039
For functions which are known to return their argument,
isDereferenceableAndAlignedPointer can examine the argument value.
Differential Revision: http://reviews.llvm.org/D9384
llvm-svn: 275038
When building SCEVs, if a function is known to return its argument, then we can
build the SCEV using the corresponding argument value.
Differential Revision: http://reviews.llvm.org/D9381
llvm-svn: 275037
If a function is known to return one of its arguments, we can use that in order
to compute known bits of the return value.
Differential Revision: http://reviews.llvm.org/D9397
llvm-svn: 275036
Motivated by the work on the llvm.noalias intrinsic, teach BasicAA to look
through returned-argument functions when answering queries. This is essential
so that we don't loose all other AA information when supplementing with
llvm.noalias.
Differential Revision: http://reviews.llvm.org/D9383
llvm-svn: 275035
In order to make the optimizer smarter about using the 'returned' argument
attribute (generally, but motivated by my llvm.noalias intrinsic work), add a
utility function to Call/InvokeInst, and CallSite, to make it easy to get the
returned call argument (when one exists).
P.S. There is already an unfortunate amount of code duplication between
CallInst and InvokeInst, and this adds to it. We should probably clean that up
separately.
Differential Revision: http://reviews.llvm.org/D22204
llvm-svn: 275031
Calls to matchVectorShuffleAsInsertPS only need to ensure the inputs are 128-bit vectors. Only lowerVectorShuffleAsInsertPS needs to ensure that they are v4f32.
llvm-svn: 275028
A function can have one argument with the 'returned' attribute, indicating that
the associated argument is always the return value of the function. Add
FuncAttrs inference logic.
Differential Revision: http://reviews.llvm.org/D22202
llvm-svn: 275027
The description of the 'returned' attribute says that it is only used when
code-generating the caller. I'd like to make the optimizer smarter about
looking through functions with returned arguments (generally, but motivated by
my llvm.noalias work). As David pointed out in the review of D22202, the
LangRef should be updated to make its expanded uses clearer.
Differential Revision: http://reviews.llvm.org/D22205
llvm-svn: 275026
This adds a new SystemZ-specific intrinsic, llvm.s390.tdc.f(32|64|128),
which maps straight to the test data class instructions. A new IR pass
is added to recognize instructions that can be converted to TDC and
perform the necessary replacements.
Differential Revision: http://reviews.llvm.org/D21949
llvm-svn: 275016
There is no polymorphism here, and StreamRef already contains a
StreamInterface pointer. Dropping the base class makes StreamRef more
transparent to the compiler, for example it can find unused variables.
llvm-svn: 275013
Some abstractions in LLVM "know" that they are reading in-bounds,
FixedStreamArray, and provide a simple result. This breaks down if the
stream map is bogus.
llvm-svn: 275010
We are currently using add_llvm_utility for executable targets that:
1. Are built by default.
2. Used for testing.
3. Are not installed by default.
Originally, lli-child-target used add_llvm_tool instead of add_llvm_executable
directly. This was changed so that lli-child-target would not be installed. This
was good since this is only used for testing and should never be installed for
users. This also had the unfortunate side effect that one can never turn off the
building of lli-child-target by default, a regression for projects that by
default do not want to compile any LLVM tools beyond tablegen/llvm-config.
This patch changes lli-child-target to use add_llvm_utility. This makes sense
since:
1. lli-child-target matches the semantics of executables created with
add_llvm_utility.
2. We fix the regression since now one can use the flag LLVM_BUILD_UTILS to
eliminate default compilation.
llvm-svn: 275008
This option is the equivalent option to LLVM_BUILD_TOOLS but for executables
created via add_llvm_utility.
This is a useful tool for improving compile time in situations where LLVM is
used as a library and no testing tools are needed.
It follows the exact same implemention model as LLVM_BUILD_TOOLS.
Since the option is by default set to on, no behavior is changed unless one sets
it from the command line to be false.
llvm-svn: 275007
In the solver, isUndefined() does really mean "we don't know the
value yet" rather than "this is an UndefinedValue". Discussed with
Eli Friedman.
Differential Revision: http://reviews.llvm.org/D22192
llvm-svn: 275004
This code was already commented out and it made some weird assumptions,
e.g. using isUndefined() as "this value is UndefValue" instead of
"we haven't computed this value is yet". Thanks to Eli Friedman for
pointing out where I was wrong (and where this code was wrong).
llvm-svn: 274995
ConstantInt::getSExtValue may fail on >64-bit integers. Add checks to call
getSExtValue only on narrow integers.
As a minor aside, simplify slsr-gep.ll to remove unnecessary load instructions.
llvm-svn: 274982
