This unbreaks TripleTest.Normalization. We'll have to come up with a new
plan for the OS component of the target triple for WebAssembly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241041 91177308-0d34-0410-b5e6-96231b3b80d8
When GlobalOpt has determined that a GlobalVariable only ever has two values,
it would convert the GlobalVariable to a boolean, and introduce SelectInsts
at every load, to choose between the two possible values. These SelectInsts
introduce overhead and other unpleasantness.
This patch makes GlobalOpt just add range metadata to loads from such
GlobalVariables instead. This enables the same main optimization (as seen in
test/Transforms/GlobalOpt/integer-bool.ll), without introducing selects.
The main downside is that it doesn't get the memory savings of shrinking such
GlobalVariables, but this is expected to be negligible.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204076 91177308-0d34-0410-b5e6-96231b3b80d8
operator<< so that functions are printed as just their name instead of as their
entire definition, which is excessively verbose in this context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183871 91177308-0d34-0410-b5e6-96231b3b80d8
/dev/stdin as an input when stdin is connected to a tty, for example.
No test, because it's difficult to write a reasonably portable test
for this. /dev/stdin isn't a character device when stdin is redirected
from a file or connected to a pipe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175542 91177308-0d34-0410-b5e6-96231b3b80d8
remaining use of AliasAnalysis concepts such as isIdentifiedObject to
prove pointer inequality.
@external_compare in test/Transforms/InstSimplify/compare.ll shows a simple
case where a noalias argument can be equal to a global variable address, and
while AliasAnalysis can get away with saying that these pointers don't alias,
instsimplify cannot say that they are not equal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174122 91177308-0d34-0410-b5e6-96231b3b80d8
be equal, since there's nothing preventing a caller from correctly predicting
the stack location of an alloca.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174119 91177308-0d34-0410-b5e6-96231b3b80d8
it isn't really an AliasAnalysis concept, and ValueTracking has similar things
that it could plausibly share code with some day.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174027 91177308-0d34-0410-b5e6-96231b3b80d8
reference to a pointer, so that it can handle the case where DataLayout
is not available and behave conservatively.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174024 91177308-0d34-0410-b5e6-96231b3b80d8
for example, a one-past-the-end pointer from one global variable may
be equal to the base pointer of another global variable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173995 91177308-0d34-0410-b5e6-96231b3b80d8
Dan Gohman