llvm-svn: 14789

the funciton symbol table to check for conflicts instead of having to
keep a shadow named LocalSymtab.  Totally eliminate LocalSymtab.  Verified
that this did not cause a regression on the testcase for PR107.

llvm-svn: 14788

  1. Split setValueName into two separate functions, one that is only used
     at function scope and doesn't have to deal with duplicates, and one
     that can be used either at global or function scope but that does deal
     with conflicts.  Conflicts were only in there because of the crappy old
     CFE and probably should be entirely eliminated.
  2. Insert BasicBlock's into the parent functions when they are created
     instead of when they are complete.  This effects name lookup (for the
     better), which will be exploited in the next patch.

llvm-svn: 14787

code.

llvm-svn: 14785

llvm-svn: 14724

llvm-svn: 14707

  any more. Needed for bug 122
- #include <iostream> since Value.h doesn't include it any more.

llvm-svn: 14621

for bug 122 since the "Type Type" concept is gone now.

llvm-svn: 14620

llvm-svn: 14201

llvm-svn: 13862

break when Type::TypeTy goes away. Also remove a dead block of code and
dead comments.

llvm-svn: 13861

llvm-svn: 13837

function to llvmAsmParser.y and then use it in the one place in the grammar
that needs it. Also had to make Type::setName public because setTypeName
needs it in order to retain compatibility with setValueName.

llvm-svn: 13795

Reid cringe :)

llvm-svn: 13788

llvm-svn: 13758

llvm-svn: 13023

types and can have arbitrary 32- and 64-bit integer types indexing into
sequential types.

Auto-upgrade .ll files that use ubytes to index into structures to use uint's.

llvm-svn: 12652

llvm-svn: 12566

llvm-svn: 12551

it was "reachable".  Cute.

llvm-svn: 12515

llvm-svn: 12313

I introduced last night.  Note to self: test the *correct* tree...

llvm-svn: 12220

llvm-svn: 12212

in this for programs with lots of types (like the testcase in PR224).
The problem was that the type ID that the outer vector was using was not
very dense (as many types are getting resolved), so the vector is large
and gets reallocated a lot.

Since there are a lot of values in the program (the .ll file is 10M),
each reallocation has to copy the subvectors, which is also quite slow
(this wouldn't be a problem if C++ supported move semantics, but it
doesn't, at least not yet :(

Changing the outer data structure to a map speeds a release build of
llvm-as up from 11.21s to 5.13s on the testcase in PR224.

llvm-svn: 11244

type at the same time, resolve the upreferences to each other before resolving
it to the outer type.  This shaves off some time from the testcase in PR224, from
25.41s -> 21.72s.

llvm-svn: 11241

llvm-svn: 11228

llvm-svn: 11224

llvm-svn: 11222

contains the type we are looking for, just search the immediately used types.
We can only do this because we keep the "current" type in the nesting level
as we decrement upreferences.

This change speeds up the testcase in PR224 from 50.4s to 22.08s, not
too shabby.

llvm-svn: 11221

type from containing one.  This speeds up the asmparser on the testcase in PR224 from
61->50s.

llvm-svn: 11220

allow 'except' instead of 'unwind' here though.

llvm-svn: 11203

llvm-svn: 10791

compile when enabled.

llvm-svn: 10657

llvm-svn: 10599

constructed!

llvm-svn: 10598

llvm-svn: 10596

llvm-svn: 10236

llvm-svn: 10204

llvm-svn: 10146

llvm-svn: 10132