llvm-svn: 81052

llvm-svn: 81051

preparation of supporting other targets. Then changed the lexer to parse these
as tokens.

llvm-svn: 81050

supporting other targets.  Changed the code to pass MCAsmInfo to the parser
and the lexer.  Then changed the lexer to use CommentString from MCAsmInfo
instead of a literal '#' character.

llvm-svn: 81046

MDNode's operand list does not include all elements.

llvm-svn: 81045

llvm-svn: 81044

llvm-svn: 81042

llvm-svn: 81041

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

llvm-svn: 81038

(Keep disabled test disabled until selfhosted build issue is resolved.)

llvm-svn: 81008

(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: 80986

llvm-svn: 80985

llvm-svn: 80983

llvm-svn: 80978

llvm-svn: 80976

llvm-svn: 80975

llvm-svn: 80971

llvm-svn: 80970

introduced regressions in the Ocaml bindings tests.

llvm-svn: 80969

There's a bug with ocamlc that uses "char*" instead of "const char*" for
global string variables. This causes g++ to be very noisy when linking
ocamlc programs. That's why the ocaml test used to cat to /dev/null.
ocamlopt doesn't have this problem, so we can get rid of the >/dev/null,
which may obscure some problems.

llvm-svn: 80968

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

llvm-svn: 80965

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

Add or Remove operation complete, and not while building the intermediate tree.
This trades a little bit more memory usage for less accesses to the FoldingSet.  On a benchmark for the clang static analyzer, this shaves off another 13% of execution time when using field/array sensitivity.

llvm-svn: 80955

on a self-hosted build (although it seems to work on non-self hosted). I'll work
with Andreas to figure this out.

llvm-svn: 80947

llvm-svn: 80946

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