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
is found. Instead of complaining about a generic "unused expr",
emit:
t.m:7:3: warning: property access result unused - getters should not have side effects
While objc property getters *could* have side effects, according to
the language best practices, they *shouldn't*. Hopefully the
diagnostic now gets this across.
llvm-svn: 79192
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
Jakob Stoklund Olesen