llvm-svn: 207394

llvm-svn: 207196

behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
  can do so by defining the macro before their inline code and undef-ing
  it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
  different DEBUG_TYPE definitions. This may be mostly an academic
  violation today, but with modules these types of violations are easy
  to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

llvm-svn: 206822

IR types.

llvm-svn: 202827

llvm-svn: 200611

avoid a heap allocation when this is the case.

llvm-svn: 192602

standards for LLVM. Remove duplicated comments on the interface from the
implementation file (implementation comments are left there of course).
Also clean up, re-word, and fix a few typos and errors in the commenst
spotted along the way.

This is in preparation for changes to these files and to keep the
uninteresting tidying in a separate commit.

llvm-svn: 187335

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

SSAUpdater was created and destroyed without being initialized.

llvm-svn: 162137

LICM uses AliasSet information to hoist and sink instructions. However, other passes, such as LoopRotate
may invalidate its AliasSet because SSAUpdater does not update the AliasSet properly.
This patch teaches SSAUpdater to notify AliasSet that it made changes.
The testcase in PR12901 is too big to be useful and I could not reduce it to a normal size. 

rdar://11872059 PR12901

llvm-svn: 161803

The name (and comment describing) of llvm::GetFirstDebuigLocInBasicBlock no longer represents what the function does. Therefore, the function is removed and its functionality is folded into the only place in the code-base where it was being used.

llvm-svn: 159133

I'll admit I'm not entirely satisfied with this change, but it seemed
the cleanest option. Other suggestions quite welcome

The issue is that the traits specializations have static methods which
return the typedef'ed PHI_iterator type. In both the IR and MI layers
this is typedef'ed to a custom iterator class defined in an anonymous
namespace giving the types and the functions returning them internal
linkage. However, because the traits specialization is defined in the
'llvm' namespace (where it has to be, specialized template lives there),
and is in turn used in the templated implementation of the SSAUpdater.
This led to the linkage conflict that Clang now warns about.

The simplest solution to me was just to define the PHI_iterator as
a nested class inside the trait specialization. That way it still
doesn't get scoped widely, it can't be accidentally reused somewhere,
etc. This is a little gross just because nested class definitions are
a little gross, but the alternatives seem more ad-hoc.

llvm-svn: 158799

llvm-svn: 144536

llvm-svn: 135375

mallocs.

llvm-svn: 135366

llvm-svn: 134538

llvm-svn: 131956

promoting allocas to SSA variables. Fixes <rdar://problem/9479036>.

llvm-svn: 131953

llvm-svn: 130551

llvm-svn: 129271

PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128537

code.

llvm-svn: 124100

to use it.

llvm-svn: 123501

"promote a bunch of load and stores" logic, allowing the code to
be shared and reused.

llvm-svn: 123456

rather than calling hasConstantValue.  No intended functionality change.

llvm-svn: 119352

I'm sure it is harmless.  Original commit message:
If PrototypeValue is erased in the middle of using the SSAUpdator
then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112810

self host errors on clang-x86-64.

llvm-svn: 112719

then the SSAUpdator may access freed memory.  Instead, simply pass
in the type and name explicitly, which is all that was used anyway.

llvm-svn: 112699

llvm-svn: 112409

MachineSSAUpdater to avoid duplicating all the code.

llvm-svn: 103060

GCCAS time for MultiSource/Benchmarks/ASCI_Purple/SMG2000.

llvm-svn: 102009

to determine where to place PHIs by iteratively comparing reaching definitions
at each block.  That was just plain wrong.  This version now computes the
dominator tree within the subset of the CFG where PHIs may need to be placed,
and then places the PHIs in the iterated dominance frontier of each definition.
The rest of the patch is mostly the same, with a few more performance
improvements added in.

llvm-svn: 101612

(what was I thinking?) and there's also a problem with LCSSA.  I'll try again
later with fixes.

--- Reverse-merging r100263 into '.':
U    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100177 into '.':
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100148 into '.':
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100147 into '.':
U    include/llvm/Transforms/Utils/SSAUpdater.h
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100131 into '.':
G    include/llvm/Transforms/Utils/SSAUpdater.h
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100130 into '.':
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100126 into '.':
G    include/llvm/Transforms/Utils/SSAUpdater.h
G    lib/Transforms/Utils/SSAUpdater.cpp
--- Reverse-merging r100050 into '.':
D    test/Transforms/GVN/2010-03-31-RedundantPHIs.ll
--- Reverse-merging r100047 into '.':
G    include/llvm/Transforms/Utils/SSAUpdater.h
G    lib/Transforms/Utils/SSAUpdater.cpp

llvm-svn: 100264

llvm-svn: 100263

llvm-svn: 100177

llvm-svn: 100164

This is more efficient than adding them to the worklist and then ignoring them.

llvm-svn: 100158

llvm-svn: 100148

llvm-svn: 100147