otherwise, opt might crash.

llvm-svn: 52041

crash the opt. Just fix this.

Test case in llvm/test/Transforms/InstCombine/2008-06-05-ashr-crash.ll

llvm-svn: 52003

work and how to replace them into individual values. Also, when trying to
replace an aggregrate that is used by load or store with a single (large)
integer, don't crash (but don't replace the aggregrate either).

Also adds a testcase for both structs and arrays.

llvm-svn: 51997

deprecated by the GVN and GVNPRE passes.

llvm-svn: 51983

llvm-svn: 51955

are the same as in unpacked structs, only field
positions differ.  This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment.  Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done.  I now
think this was a mistake.  Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes.  It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.

llvm-svn: 51928

llvm-svn: 51887

llvm-svn: 51864

out of instcombine into a new file in libanalysis.  This also teaches
ComputeNumSignBits about the number of sign bits in a constantint.

llvm-svn: 51863

char a[200];
init(a, a+200);

OR

int a[200];
char* b = (char*)a;
char* c = (char*)a;
foo(b, c);

llvm-svn: 51850

llvm-svn: 51848

the conditions for performing the transform when only the
function declaration is available: no longer allow turning
i32 into i64 for example.  Only allow changing between
pointer types, and between pointer types and integers of
the same size.  For return values ptr -> intptr was already
allowed; I added ptr -> ptr and intptr -> ptr while there.
As shown by a recent objc testcase, changing the way
parameters/return values are passed can be fatal when calling
code written in assembler that directly manipulates call
arguments and return values unless the transform has no
impact on the way they are passed at the codegen level.
While it is possible to imagine an ABI that treats integers
of pointer size differently to pointers, I don't think LLVM
supports any so the transform should now be safe while still
being useful.

llvm-svn: 51834

llvm-svn: 51819

llvm-svn: 51817

llvm-svn: 51816

llvm-svn: 51698

llvm-svn: 51680

the one case that ADCE catches that normal DCE doesn't: non-induction variable
loop computations.

This implementation handles this problem without using postdominators.

llvm-svn: 51668

llvm-svn: 51666

llvm-svn: 51636

llvm-svn: 51591

the set of nodes. Fix makeEqual to handle this by creating the new node first
then iterating across them second.

llvm-svn: 51573

llvm-svn: 51572

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.

llvm-svn: 51559

This fixes PR2359

llvm-svn: 51536

llvm-svn: 51535

Remove x86.sse2.loadh.pd and x86.sse2.loadl.pd. These will be lowered into load and shuffle instructions.

llvm-svn: 51521

use it instead of duplicating its functionality.

llvm-svn: 51499

llvm-svn: 51482

llvm-svn: 51476

llvm-svn: 51475

llvm-svn: 51474

llvm-svn: 51472

llvm-svn: 51471

and/or to handle more cases (such as this add-sitofp.ll testcase), and
port it to selectiondag's ComputeNumSignBits.

llvm-svn: 51469

exclude struct and array types.

llvm-svn: 51467

in gcc.dg/pr27531-1.c.

llvm-svn: 51464

exclude struct and array types.

llvm-svn: 51456

more aggressive, and more correct.  Verify that we only attempt to
promote loads and stores.

llvm-svn: 51406

llvm-svn: 51399