Subzero: Change the way bitcast stack slot lowering is handled.

Subzero: Change the way bitcast stack slot lowering is handled.

When doing a bitcast between int and FP types, the way lowering works
is that a spill temporary is created, with regalloc weight of zero to
inhibit register allocation, and this spill temporary is used for the
cvt instruction.  If the other variable does not get
register-allocated, then addProlog() forces the spill temporary to
share the same stack slot as the other variable.

Currently, the lowering code passes this information to addProlog()
by using the setPreferredRegister() mechanism.

This is changed by creating a target-specific subclass of Variable, so
that only the spill temporaries need to carry this extra information.

Ultimately, many of the existing Variable fields will be refactored
into a separate structure, and only generated/used as needed by
various optimization passes.  The spill temporary linkage is the one
thing that is still needed with Om1 when no optimizations are enabled,
motivating this change.

A couple other minor cleanups are also done here.

The key test is that the cast cross tests continue to work,
specifically the bitcast tests.

BUG= none
R=jvoung@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=800dab29d19d6cc9e842fc16bfb9433018322062

[Jim Stichnoth, 2014-09-20 00:09:26]

stichnot@chromium.org changed reviewers:
+ jvoung@chromium.org

[jvoung (off chromium), 2014-09-20 18:30:56]

LGTM

https://codereview.chromium.org/586943003/diff/1/src/IceOperand.cpp
File src/IceOperand.cpp (right):

https://codereview.chromium.org/586943003/diff/1/src/IceOperand.cpp#newcode192
src/IceOperand.cpp:192: Variable V(kVariable, Ty, DefNode, Number, Name);
Should it use the original Kind, instead of kVariable?

[Jim Stichnoth, 2014-09-20 19:24:53]

https://codereview.chromium.org/586943003/diff/1/src/IceOperand.cpp
File src/IceOperand.cpp (right):

https://codereview.chromium.org/586943003/diff/1/src/IceOperand.cpp#newcode192
src/IceOperand.cpp:192: Variable V(kVariable, Ty, DefNode, Number, Name);
On 2014/09/20 18:30:56, jvoung wrote:
> Should it use the original Kind, instead of kVariable?

I don't think so, because then you could do something like
llvm::cast<VariableSpill>(&V)->getLinkedTo(), which would pass all the
compile-time and run-time checks, but would be incorrect.

I'll add a comment to clarify the limitations of asType().  BTW, hopefully we
can get rid of this sketchy function with the new assembler.

[Jim Stichnoth, 2014-09-20 19:25:05]

Committed patchset #2 (id:20001) manually as 800dab2 (presubmit successful).