- Jun 05, 2010
-
-
Stuart Hastings authored
llvm-svn: 105511
-
Dan Gohman authored
there could be multiple subexpressions within a single expansion which require insert point adjustment. This fixes PR7306. llvm-svn: 105510
-
Dale Johannesen authored
I don't think this ever resulted in problems on x86, but it would on ARM. llvm-svn: 105509
-
Evan Cheng authored
llvm-svn: 105502
-
Dan Gohman authored
register pressure. llvm-svn: 105501
-
-
Stuart Hastings authored
llvm-svn: 105492
-
Devang Patel authored
Copy location info for current function argument from dbg.declare if respective store instruction does not have any location info. llvm-svn: 105490
-
- Jun 04, 2010
-
-
Jim Grosbach authored
llvm-svn: 105481
-
Dan Gohman authored
llvm-svn: 105480
-
Jakob Stoklund Olesen authored
register allocation. Process all of the clobber lists at the end of the function, marking the registers as used in MachineRegisterInfo. This is necessary in case the calls clobber callee-saved registers (sic). llvm-svn: 105473
-
Dale Johannesen authored
8060143, although this doesn't fix the real problem with tail call. llvm-svn: 105472
-
-
Jim Grosbach authored
llvm-svn: 105454
-
Mon P Wang authored
replace an OpA with a widened OpB, it is possible to get new uses of OpA due to CSE when recursively updating nodes. Since OpA has been processed, the new uses are not examined again. The patch checks if this occurred and it it did, updates the new uses of OpA to use OpB. llvm-svn: 105453
-
Jim Grosbach authored
llvm-svn: 105441
-
Bob Wilson authored
VECTOR_SHUFFLEs to REG_SEQUENCE instructions. The standard ISD::BUILD_VECTOR node corresponds closely to REG_SEQUENCE but I couldn't use it here because its operands do not get legalized. That is pretty awful, but I guess it makes sense for other targets. Instead, I have added an ARM-specific version of BUILD_VECTOR that will have its operands properly legalized. This fixes the rest of Radar 7872877. llvm-svn: 105439
-
Bob Wilson authored
Check that all the instructions are in the same basic block, that the EXTRACT_SUBREGs write to the same subregs that are being extracted, and that the source and destination registers are in the same regclass. Some of these constraints can be relaxed with a bit more work. Jakob suggested that the loop that checks for subregs when NewSubIdx != 0 should use the "nodbg" iterator, so I made that change here, too. llvm-svn: 105437
-
Jim Grosbach authored
llvm-svn: 105435
-
Jim Grosbach authored
llvm-svn: 105427
-
- Jun 03, 2010
-
-
Dale Johannesen authored
A temporary flag -arm-tail-calls defaults to off, so there is no functional change by default. Intrepid users may try this; simple cases work but there are bugs. llvm-svn: 105413
-
Dan Gohman authored
needs to demand the high bits because it's asserting that they're zero. llvm-svn: 105406
-
Bob Wilson authored
llvm-svn: 105399
-
Bill Wendling authored
registers it defines then interfere with an existing preg live range. For instance, if we had something like these machine instructions: BB#0 ... = imul ... EFLAGS<imp-def,dead> test ..., EFLAGS<imp-def> jcc BB#2 EFLAGS<imp-use> BB#1 ... ; fallthrough to BB#2 BB#2 ... ; No code that defines EFLAGS jcc ... EFLAGS<imp-use> Machine sink will come along, see that imul implicitly defines EFLAGS, but because it's "dead", it assumes that it can move imul into BB#2. But when it does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and messes up the condition code for the jump (and pretty much anything else which relies upon it being correct). The solution is to know which pregs are live going into a basic block. However, that information isn't calculated at this point. Nor does the LiveVariables pass take into account non-allocatable physical registers. In lieu of this, we do a *very* conservative pass through the basic block to determine if a preg is live coming out of it. llvm-svn: 105387
-
Eric Christopher authored
llvm-svn: 105381
-
Eric Christopher authored
llvm-svn: 105379
-
Eli Friedman authored
expansion is the same as that used by LegalizeDAG. The resulting code sucks in terms of performance/codesize on x86-32 for a 64-bit operation; I haven't looked into whether different expansions might be better in general. llvm-svn: 105378
-
Eli Friedman authored
llvm-svn: 105377
-
Eli Friedman authored
llvm-svn: 105376
-
Eli Friedman authored
llvm-svn: 105375
-
Jakob Stoklund Olesen authored
This affects both llvm-gcc and clang. llvm-svn: 105372
-
Jakob Stoklund Olesen authored
spills and reloads. This means that a partial define of a register causes a reload so the other parts of the register are preserved. The reload can be prevented by adding an <imp-def> operand for the full register. This is already done by the coalescer and live interval analysis where relevant. llvm-svn: 105369
-
Jakob Stoklund Olesen authored
register updates. These operands tell the spiller that the other parts of the partially defined register are don't-care, and a reload is not necessary. llvm-svn: 105361
-
Devang Patel authored
Speedup bitcode writer. Do not walk all values for all functions to emit function local metadata. In one testcase, probably worst case scenario, the 70x speed up is seen. llvm-svn: 105360
-
Bill Wendling authored
llvm-svn: 105359
-
Jakob Stoklund Olesen authored
instruction defines subregisters. Any existing subreg indices on the original instruction are preserved or composed with the new subreg index. Also substitute multiple operands mentioning the original register by using the new MachineInstr::substituteRegister() function. This is necessary because there will soon be <imp-def> operands added to non read-modify-write partial definitions. This instruction: %reg1234:foo = FLAP %reg1234<imp-def> will reMaterialize(%reg3333, bar) like this: %reg3333:bar-foo = FLAP %reg333:bar<imp-def> Finally, replace the TargetRegisterInfo pointer argument with a reference to indicate that it cannot be NULL. llvm-svn: 105358
-
- Jun 02, 2010
-
-
Jim Grosbach authored
llvm-svn: 105350
-
Rafael Espindola authored
llvm-svn: 105344
-
Eli Friedman authored
backend. Add a FIXME noting what can be fixed here. llvm-svn: 105342
-
Dan Gohman authored
mailing list archives. llvm-svn: 105341
-