about by icc (#593, partial).  Patch by Erick Tryzelaar.

llvm-svn: 81115

1. DUPMAX is defined in regcomp.c, no need to redefine it in regutils.
2. MSVC doesn't like snprintf, use _snprintf instead.

llvm-svn: 81114

(#411).  Patch by Erick Tryzelaar.

llvm-svn: 81113

llvm-svn: 81112

doesn't warn about unreachable instructions.  Patch
by Erick Tryzelaar (#111).

llvm-svn: 81110

llvm-svn: 81108

Patch by Erick Tryzelaar.

llvm-svn: 81107

icc (#177, partial).  Patch by Erick Tryzelaar.

llvm-svn: 81106

 - I think there are more instances of this, but I think they are fixed in Dan's
   incoming patch. This one was preventing me from doing a bugpoint reduction
   though.

llvm-svn: 81103

llvm-svn: 81101

breaks MiniSAT on x86_64.

llvm-svn: 81098

Do not use DenseMap operator[] because it inserts new entry if lookup fails. Use find() to check an entry in a DenseMap first.

llvm-svn: 81058

llvm-svn: 81055

MDNode's operand list does not include all elements.

llvm-svn: 81045

llvm-svn: 81044

a new class, MachineInstrIndex, which hides arithmetic details from
most clients. This is a step towards allowing the register allocator
to update/insert code during allocation.

llvm-svn: 81040

(See http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090831/086219.html)

llvm-svn: 81007

into llvm/ADT.

llvm-svn: 81001

Constant uniquing tables. This allows distinct ConstantExpr objects
with the same operation and different flags.

Even though a ConstantExpr "a + b" is either always overflowing or
never overflowing (due to being a ConstantExpr), it's still necessary
to be able to represent it both with and without overflow flags at
the same time within the IR, because the safety of the flag may
depend on the context of the use. If the constant really does overflow,
it wouldn't ever be safe to use with the flag set, however the use
may be in code that is never actually executed.

This also makes it possible to merge all the flags tests into a single test.

llvm-svn: 80998

llvm-svn: 80997

llvm-svn: 80994

llvm-svn: 80993

llvm-svn: 80978

llvm-svn: 80976

llvm-svn: 80971

llvm-svn: 80970

introduced regressions in the Ocaml bindings tests.

llvm-svn: 80969

D    test/Analysis/Profiling

--- Reverse-merging r80907 into '.':
U    lib/Analysis/ProfileInfoLoaderPass.cpp

Attempt to remove failure in the self-hosting build bot.

llvm-svn: 80966

FastISel to recognize this pattern and emit a floating-point
negation using xor.

llvm-svn: 80963

llvm-svn: 80962

(i.e., there are no local variables and stuff), we still need to output FDE
information for the pushed registers.

llvm-svn: 80960

and exact flags. Because ConstantExprs are uniqued, creating an
expression with this flag causes all expressions with the same operands
to have the same flag, which may not be safe. Add, sub, mul, and sdiv
ConstantExprs are usually folded anyway, so the main interesting flag
here is inbounds, and the constant folder already knows how to set the
inbounds flag automatically in most cases, so there isn't an urgent need
for the API support.

This can be reconsidered in the future, but for now just removing these
API bits eliminates a source of potential trouble with little downside.

llvm-svn: 80959

Create our own block initializer for kill fixups as the scheduling one wasn't doing the right thing.

llvm-svn: 80958

llvm-svn: 80956

for the complicated case where one register is tied to multiple destinations.
This avoids the extra scan of instruction operands that was introduced by
my recent change.  I also pulled some code out into a separate
TryInstructionTransform method, added more comments, and renamed some
variables.

Besides all those changes, this takes care of a FIXME in the code regarding
an assumption about there being a single tied use of a register when
converting to a 3-address form.  I'm not aware of cases where that assumption
is violated, but the code now only attempts to transform an instruction,
either by commuting its operands or by converting to a 3-address form,
for the simple case where there is a single pair of tied operands.

llvm-svn: 80945

llvm-svn: 80942

llvm-svn: 80941

swapping the operands if necessary.

llvm-svn: 80940

  - when transforming a vector shift of a non-immediate scalar shift amount, zero
    extend the i32 shift amount to i64 since the vector shift reads 64 bits
  - when transforming i16 vectors to use a vector shift, zero extend i16 shift amount
  - improve the code quality in some cases when transforming vectors to use a vector shift

llvm-svn: 80935

disabling the use of 16-bit operations on x86. This doesn't yet work for
inline asms with 16-bit constraints, vectors with 16-bit elements,
trampoline code, and perhaps other obscurities, but it's enough to try
some experiments.

llvm-svn: 80930