convention.  Patch by David Terei!

llvm-svn: 98212

Radar 7686922.

llvm-svn: 98210

Move methods out of line and M-x whitespace-cleanup.
Promote common method arguments to member variables.

llvm-svn: 98207

which doesn't support .quad correctly because it is
"really really old".  PR6528.

Yet another reason the mc assembler should take over ;-)

llvm-svn: 98205

when it looked past a trunc.

llvm-svn: 98203

llvm-svn: 98202

Patch by Sean Callanan.

llvm-svn: 98200

indicates that an MCSymbol is external or not. (It's true if it's external.)
This will be used to specify the correct information to add to non-lazy
pointers. That will be explained further when this bit is used.

llvm-svn: 98199

No functional effect yet.  This is still evolving and should
not be viewed as final.

llvm-svn: 98195

llvm-svn: 98194

patch by Micah Villmow for PR6572.

llvm-svn: 98188

llvm-svn: 98187

llvm-svn: 98186

400.perlbench for the nightly tests.

llvm-svn: 98183

llvm-svn: 98182

llvm-svn: 98181

compute a set of reachable blocks for itself each time it is called, which
is fairly frequently.

llvm-svn: 98179

llvm-svn: 98178

operands into their own PrintMethod, in order not to pollute the printOperand()
impl with disassembly only Imm modifiers.

llvm-svn: 98172

llvm-svn: 98169

expression add(add(mul(x,y),a),b) -> lmul(x,y,a,b) if all
operands are zero extended.

llvm-svn: 98168

llvm-svn: 98167

llvm-svn: 98164

into a seperate function.

llvm-svn: 98162

llvm-svn: 98158

results are unused elsewhere.

llvm-svn: 98157

llvm-svn: 98156

I'll get this loop right yet.

llvm-svn: 98155

llvm-svn: 98153

llvm-svn: 98152

llvm-svn: 98151

directly to the maccu / maccs instructions. We handle this in
ExpandADDSUB since after type legalisation it is messy to
recognise these operations.

llvm-svn: 98150

semantic instead of syntactic.  This completes MCization of
darwin/x86[-64]!

llvm-svn: 98145

llvm-svn: 98137

llvm-svn: 98132

for darwin/x86 to be completely mcized.

llvm-svn: 98130

llvm-svn: 98125

llvm-svn: 98124

llvm-svn: 98122

1. Be careful with cse "cheap" expressions. e.g. constant materialization. Only cse them when the common expression is local or in a direct predecessor. We don't want cse of cheap instruction causing other expressions to be spilled.
2. Watch out for the case where the expression doesn't itself uses a virtual register. e.g. lea of frame object. If the common expression itself is used by copies (common for passing addresses to function calls), don't perform the cse. Since these expressions do not use a register, it creates a live range but doesn't close any, we want to be very careful with increasing register pressure.

Note these are heuristics so machine cse doesn't make register allocator unhappy. Once we have proper live range splitting and re-materialization support in place, these should be evaluated again.

Now machine cse is almost always a win on llvm nightly tests on x86 and x86_64.

llvm-svn: 98121