Closed Bug 1710087 Opened 5 years ago Closed 20 days ago

ARM64: Use the zero register for zero constants when possible

Categories

(Core :: JavaScript: WebAssembly, enhancement, P3)

ARM64
All
enhancement

Tracking

()

RESOLVED FIXED
152 Branch
Tracking Status
firefox152 --- fixed

People

(Reporter: lth, Assigned: yury)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

This may be tricky to do except in limited contexts because of the risk of confusing the zero register with the stack pointer, and how often is the zero value used for anything but initialization anyway, but in principle when a zero value is needed we should use the zero register.

Consider

  (func $f1 (param $p i32)
    (i32.store (local.get $p) (i32.const 0)))

The code for this is:

0x13cf8746f034  52800001  mov     w1, #0x0
0x13cf8746f038  b8206aa1  str     w1, [x21, x0]

where the first instruction is not necessary, the second could just store wzr.

Similarly, in bug 1709863 the zero value shows up in an addressing instruction, and though that addressing code should be fixed in other ways and the particular issue will go away, the situation is the same: a zero literal should not need a dedicated register.

Integer negate has a redundant zero when expressed as 0-n instead of n*-1:

0x1e381ef2b084  52800001  mov     w1, #0x0
0x1e381ef2b088  4b000020  sub     w0, w1, w0

We probably want to handle this case during lowering and generate an LNegI node (we should do this cross-platform; x86/x64 have the same problem), and we want to check that a redundant zero is not being generated in this case.

(Addressed in bug 1710403.)

See Also: → 877321
  • i32.store/store8/store16 of i32.const 0: use wzr directly
  • anyref/funcref null struct-field and array-element stores: use xzr
  • i8x16/i16x8/i32x4.replace_lane with i32.const 0: use wzr
  • storePtr(ImmWord(0)): use xzr without acquiring a scratch register
  • Add assertions that xzr is never used as an address base or index,
    since encoding 31 in that position is SP, not XZR
Assignee: nobody → ydelendik
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 20 days ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: