llvm-svn: 25078

llvm-svn: 25077

llvm-svn: 25074

llvm-svn: 25073

llvm-svn: 25072

llvm-svn: 25071

read the code.

Do not internalize debugger anchors.

llvm-svn: 25067

llvm-svn: 25066

GDB use tolerable

llvm-svn: 25064

llvm-svn: 25063

the default aa impl results.

llvm-svn: 25062

llvm-svn: 25060

llvm-svn: 25059

llvm-svn: 25058

Move brcond over and fix some imm patterns.  This may be the last change before changing the default alpha isel.

llvm-svn: 25057

llvm-svn: 25055

"All this should do is create what will eventually be the specialised
passmanagers.  Currently, the templates are inheriting them, once the
template specialisations' methods have been absorbed, patches
submitted method by method.  I'll nuke the specialisations and have
the new objects inherit directly from passmanagert, and sanitise the
world of all references to templates.
"

llvm-svn: 25053

llvm-svn: 25047

llvm-svn: 25046

llvm-svn: 25045

drop it on the floor.

llvm-svn: 25044

llvm-svn: 25041

let us get some do what I meant not what I said stuff checked in.  You would think the alpha backend would be 64bit clean

llvm-svn: 25040

llvm-svn: 25039

llvm-svn: 25034

llvm-svn: 25031

llvm-svn: 25030

llvm-svn: 25028

args >8 put into the wrong place

llvm-svn: 25027

llvm-svn: 25026

llvm-svn: 25025

llvm-svn: 25024

llvm-svn: 25023

llvm-svn: 25022

llvm-svn: 25021

llvm-svn: 25018

Currently tblgen cannot tell which operands in the operand list are results so
it assumes the first one is a result. This is bad. Ideally we would fix this
by separating results from inputs, e.g. (res R32:$dst),
(ops R32:$src1, R32:$src2). But that's a more distruptive change. Adding
'let noResults = 1' is the workaround to tell tblgen that the instruction does
not produces a result. It works for now since tblgen does not support
instructions which produce multiple results.

llvm-svn: 25017

llvm-svn: 25015

the bzip2 homepage, only ancient (gcc 2.7.x ?) versions of GCC
require this? It certainly isn't needed for the current bzip2
sources.

llvm-svn: 25013

to try building LLVM on HP-UX! (the Right Way seems to be to tear out
the ancient STL that HP ship and use http://incubator.apache.org/stdcxx/ )

llvm-svn: 25012