(16) into certain areas of the SPARC V9 back-end. I'm fairly sure the US IIIi's
dcache has 32-byte lines, so I'm not sure where the 16 came from. However, in
the interest of not breaking things any more than they already are, I'm going
to leave the constant alone.
llvm-svn: 12043
DSNodes, unlike other GraphTraits nodes, can have null outgoing edges, and
df_iterator doesn't take this into consideration. As a workaround, the
successor iterator now handles null nodes and 'indicates' that null has
no successors.
llvm-svn: 12025
we really don't win that much by eliminating this (not many Modules are
allocated), so it's not worth it. When we can, we should revisit this in
the future.
llvm-svn: 12023
LLVM instructions. Because it contains an explicit cast, we didn't catch it.
I guess instruction's will be annotable for the duration of the sparcv9's
existence.
llvm-svn: 11999
methods take an int or unsigned value instead of int64_t.
Also, add an 'addImm' method to the MachineInstrBuilder class, because the
fact that the hardware sign or zero extends it does not/should not matter
to the code generator. Once the old sparc backend is removed the difference
can be eliminated.
llvm-svn: 11976
all dynamically allocated LLVM values 4 bytes smaller, eliminate some vtables, and
make Value's destructor faster.
This makes Function derive from Annotation now because it is the only core LLVM
class that still has an annotation stuck onto it: MachineFunction.
MachineFunction is obviously horrible and gross (like most other annotations), but
will be the subject of refactorings later in the future. Besides many fewer
Function objects are dynamically allocated that instructions blocks, constants,
types, etc... :)
llvm-svn: 11878
other clients. The problem is that the nullVal member was left to the default
constructor to initialize, which for int's does nothing (ie, leaves it unspecified).
To get a zero value, we must use T(). It's C++ wonderful? :)
llvm-svn: 11867
pair, and look up varargs in the execution stack every time, instead of
just pushing iterators (which can be invalidated during callFunction())
around. (union GenericValue now has a "pair of uints" member, to support
this mechanism.) Fixes Bug 234.
llvm-svn: 11845
so that we always get the inline function instead. Remember, kids, like it says
in the GCC manual, "An Inline Function is As Fast As a Macro."
llvm-svn: 11815
