vector (&Formals[0]). With this change llvm-gcc builds
with expensive checking enabled for C, C++ and Fortran.
While there, change a std::vector into a SmallVector.
This is partly gratuitous, but mostly because not all
STL vector implementations define the data method (and
it should be faster).
llvm-svn: 79237
doing it directly. This requires const'izing a bunch of stuff that
took sections, but this seems like the right semantic thing to do:
emitting a label to a section shouldn't mutate the MCSection object
itself, for example.
llvm-svn: 79227
If two uses of a CopyFromReg want different regclasses, first try a common
sub-class, then fall back on the copy emitted in AddRegisterOperand. There is
no need for an assert here. The cross-class joiner usually cleans up nicely.
llvm-svn: 79193
failure with VS 9.0, nmake and cmake 2.6.4. The buildbot output does
not show the patch level of cmake, it just says 2.6.
Sadly, parallel builds are broken due to recent changes on LLVM Target
libraries and its auxiliaries (TargetInfo, AsmPrinter, AsmParser). I
have a patch for stablishing the correct dependencies, but cmake is
buggy and generates makefiles that can't handle them.
llvm-svn: 79180
unfoldable references to a PHI node in the block being folded, and disable
the transformation in that case. The correct transformation of such PHI
nodes depends on whether BB dominates Succ, and dominance is expensive
to compute here. (Alternatively, it's possible to check whether any
uses are live, but that's also essentially a dominance calculation.
Another alternative is to use reg2mem, but it probably isn't a good idea to
use that in simplifycfg.)
Also, remove some incorrect code from CanPropagatePredecessorsForPHIs
which is made unnecessary with this patch: it didn't consider the case
where a PHI node in BB has multiple uses.
llvm-svn: 79174
can asmprint:
NEW: movl "L___stack_chk_guard$non_lazy_ptr", %eax
OLD: movl L___stack_chk_guard$non_lazy_ptr, %eax
where 'new' is coming out of the MCInst version of the printer.
llvm-svn: 79170
what was there before. In "no FP mode", we weren't generating labels and unwind
table entries after each "push" instruction. While more than likely "okay", it's
not technically correct. The major thing was that the ordering of when to define
a new CFA register and at what offset wasn't correct. This would cause the
exception handling to fail in ways most miserable to users.
I also cleaned up some code a bit. There's one function which has a "return" at
the beginning, so it's never used. Should I just remove it? :-)
llvm-svn: 79139
Dan Gohman