tree eb4b9074275cb79ca91ed2696f6b16b193a567b2
parent 6649bd025e0106c372d624a736a6dfc7b8f37404
author Nicolas Capens <capn@google.com> 1612556322 -0500
committer Nicolas Capens <nicolascapens@google.com> 1613768766 +0000

Fix lowering and optimization of 64-bit absolute addresses

x86-64 does not support 64-bit immediates as absolute memory addresses.
They have to be stored in a register, which can then be used as [base].

Previously we addressed this at the SubzeroReactor level by emitting a
Bitcast from an Ice::Operand to an Ice::Variable, for which Subzero
already supported 64-bit constants as input.

This change implements X86OperandMem creation from a 64-bit constant
operand by letting legalize() move it into a GPR and using it as the
memory operand's base register.

A Reactor unit test is added to exercise this.

Another issue was that doLoadOpt() assumed all load instructions are
candidates for fusing into a subsequent instruction which takes the
result of the load. This isn't true when for 64-bit constant addresses
an instruction to copy it into a register is inserted.

For now this case is simply skipped. A future optimization could adjust
the iterators properly so the load from [base] can be fused with the
next instruction.

Lastly, it is possible for a 64-bit constant to fit within a 32-bit
immediate, in which case legalize() by default does not perform the copy
into a GPR (note this is to allow moves and calls with 64-bit
immediates, where they are legal), and simply returns the 64-bit
constant. So we must not allow legalization to an immediate in this
case. Note that while we could replace it with a 32-bit constant, it's
rare for absolute addresses to fit in this range, and it would be
non-deterministic which path is taken, so for consistency we don't
perform this optimization.

Bug: b/148272103
Change-Id: I5fcfa971dc93f2307202ee11619e84c65fe46188
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/52768
Tested-by: Nicolas Capens <nicolascapens@google.com>
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Reviewed-by: Antonio Maiorano <amaiorano@google.com>