has a different number of elements than the output.

llvm-svn: 62998

llvm-svn: 62985

handling the flaw inherent in that assumption.  :)

llvm-svn: 62984

llvm-svn: 62983

llvm-svn: 62982

llvm-svn: 62956

more accurate change loses more than it gains on
benchmarks.

llvm-svn: 62938

Also it was an empty struct, not a void after all.

llvm-svn: 62920

Thus we need to check whether the struct is empty before trying to index into
it. This fixes PR3381.

llvm-svn: 62918

Little practical effect.

llvm-svn: 62908

handling the case in Transforms/InstCombine/cast-store-gep.ll, which
is a heavily reduced testcase from Clang on x86-64.

llvm-svn: 62904

llvm-svn: 62877

There is now a direct way from value-use-iterator to incoming block in PHINode's API.
This way we avoid the iterator->index->iterator trip, and especially the costly
getOperandNo() invocation. Additionally there is now an assertion that the iterator
really refers to one of the PHI's Uses.

llvm-svn: 62869

llvm-svn: 62788

compatibility with cygwin.  Patch by Jay Foad!

llvm-svn: 62695

Besides APFloat, this involved removing code
from two places that thought they knew the
result of frem(0., x) but were wrong.

llvm-svn: 62645

llvm-svn: 62561

llvm-svn: 62546

trapping instruction be executed unconditionally.

llvm-svn: 62541

llvm-svn: 62535

llvm-svn: 62529

llvm-gcc. Most likely, it's miscompiling one of the "gen*" programs:

/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.obj/./prev-gcc/xgcc -B/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.obj/./prev-gcc/ -B/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm-gcc.install/i386-apple-darwin9.6.0/bin/ -c -g -O2 -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -mdynamic-no-pic -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../llvm-gcc.src/gcc -I../../llvm-gcc.src/gcc/build -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   -o build/gencondmd.o build/gencondmd.c
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected '}' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: warning: excess elements in struct initializer
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: warning: (near initialization for 'insn_conditions[4]')
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected '}' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:926: error: expected ',' or ';' before ')' token
../../llvm-gcc.src/gcc/config/i386/mmx.md:927: error: expected identifier or '(' before ',' token
../../llvm-gcc.src/gcc/config/i386/sse.md:3458: error: expected identifier or '(' before ',' token
...

llvm-svn: 62506

we assumed a CFG structure that would be valid when all code in 
the function is reachable, but not all code is necessarily 
reachable.  Do a simple, but horrible, CFG walk to check for this
case.

llvm-svn: 62487

llvm-svn: 62477

because of dead code, a phi could use the speculated instruction
that was not in "BB2".  Make this check explicit and tighten up 
some other corners.  This fixes PR3292.  No testcase becauase this
depends entirely on visitation order of blocks and requires a 
sequence of 8 passes to repro.

llvm-svn: 62476

check.  No functionality change.

llvm-svn: 62474

llvm-svn: 62470

doing very similar pointer capture analysis.
Factor out the common logic.  The new version
is from FunctionAttrs since it does a better
job than the version in BasicAliasAnalysis

llvm-svn: 62461

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.

llvm-svn: 62456

llvm-svn: 62384

llvm-svn: 62377

llvm-svn: 62351

llvm-svn: 62350

Clean up previous cast optimization a bit. Also make zext elimination a bit more aggressive: if it's not necessary to emit an AND (i.e. high bits are already zero), it's profitable to evaluate the operand at a different type.

llvm-svn: 62297

llvm-svn: 62279

this fixes PR3332

llvm-svn: 62271

llvm-svn: 62264

- Looking at the number of sign bits of the a sext instruction to determine  whether new trunc + sext pair should be added when its source is being evaluated in a different type.

llvm-svn: 62263

llvm-svn: 62244

my earlier patch to this file.

The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop.  This was extra bad
because register pressure later forced both base and IV into
memory.  Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this.  However,
there were side effects....

It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before.  And when inserting 
new code that feeds into a PHI, it's right to put such 
code at the original location rather than in the PHI's 
immediate predecessor(s) when the original location is outside 
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.

Also, the mechanism for keeping SCEV's corresponding to GEP's
no longer works, as the GEP might change after its SCEV
is remembered, invalidating the SCEV, and we might get a bad
SCEV value when looking up the GEP again for a later loop.  
This also couldn't happen before, as we weren't recursing
into GEP's outside the loop.

Also, when we build an expression that involves a (possibly
non-affine) IV from a different loop as well as an IV from
the one we're interested in (containsAddRecFromDifferentLoop),
don't recurse into that.  We can't do much with it and will
get in trouble if we try to create new non-affine IVs or something.

More testcases are coming.

llvm-svn: 62212