Avoid using riscv64 Operand class when not needed
Categories
(Core :: JavaScript Engine: JIT, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox153 | --- | fixed |
People
(Reporter: anba, Assigned: anba)
References
(Blocks 1 open bug)
Details
Attachments
(8 external files, 1 obsolete file)
Operand doesn't need to be used when it's directly unwrapped in the caller.
For example:
// MacroAssemblerRiscv64Compat
void unboxWasmAnyRefGCThingForGCBarrier(const Address& src, Register dest) {
UseScratchRegisterScope temps(this);
Register scratch = temps.Acquire();
MOZ_ASSERT(scratch != dest);
movePtr(ImmWord(wasm::AnyRef::GCThingMask), scratch);
loadPtr(src, dest);
ma_and(dest, dest, scratch);
}
// MacroAssemblerRiscv64
void ma_and(Register rd, Register rs, Operand rt) {
if (rt.is_imm()) {
if (is_int12(rt.immediate())) {
andi(rd, rs, rt.immediate());
} else {
UseScratchRegisterScope temps(this);
Register scratch = temps.Acquire();
ma_li(scratch, rt.immediate());
and_(rd, rs, scratch);
}
} else {
MOZ_ASSERT(rt.is_reg());
and_(rd, rs, rt.rm());
}
}
It's inefficient to first wrap the Register in Operand when ma_and will directly take a different code path for registers.
Directly calling and_ avoid this unnecessary indirection:
movePtr(ImmWord(wasm::AnyRef::GCThingMask), scratch);
loadPtr(src, dest);
and_(dest, dest, scratch);
Slightly better is to use ma_and with wasm::AnyRef::GCThingMask as the operand:
loadPtr(src, dest);
ma_and(dest, dest, ImmWord(wasm::AnyRef::GCThingMask));
And best is to directly call andi:
static_assert(is_int12(wasm::AnyRef::GCThingMask), "fits into andi");
loadPtr(src, dest);
andi(dest, dest, wasm::AnyRef::GCThingMask);
| Assignee | ||
Comment 1•5 months ago
|
||
The "ma_<op>" methods accept Operand as the right-hand side operand. Operand
is either an immediate or a register. In the concrete "ma_<op>" methods there's
directly an if-else statement to give both operand types different code paths.
That means if Operand is always a Register, it's more efficient to directly
call the underlying assembler method, e.g. prefer addw instead of ma_add32.
If Operand is always a small immediate, let's also prefer directly calling
addiw instead of ma_add32.
This avoids some unnecessary indirections and prepares for changing ma_<op>
to only accept immediates in a later part of this patch stack.
| Assignee | ||
Comment 2•5 months ago
|
||
This were either already unused or are unused after the changes from part 1.
| Assignee | ||
Comment 3•5 months ago
|
||
The previous code was excluding the range already covered through is_int12,
but both Clang and GCC can generate slightly better code when testing the
complete range from -4096 to 4094.
| Assignee | ||
Comment 4•5 months ago
|
||
Common bit-masks can be performed using only two shifts.
More optimisations can be performed using Zbs extension instructions, but
that's for another bug.
| Assignee | ||
Comment 5•5 months ago
|
||
After part 1, these methods are only called with immediates, so let's change the
argument from Operand to Imm32 resp. Imm64. Prefer Imm32/Imm64 instead
of int32_t/int64_t to avoid implicit conversions.
Also change "MacroAssembler-riscv64-inl.h" to call the ma_<op> methods to
improve code generation for small immediates.
| Assignee | ||
Comment 6•5 months ago
|
||
Similar to the "ma_<op>" methods, also split the rotate instructions in two
different implementations for Register and Imm32 operands.
| Assignee | ||
Comment 7•5 months ago
|
||
Operand::Tag::FREGandOperand::Tag::MEMaren't used and can be removed.- The
CodeGeneratorRiscv64::ToOperand()methods are also unused. - Additionally make the
Operand(Register)constructorexplicit.
| Assignee | ||
Comment 8•5 months ago
|
||
To match ma_and which also performs similar optimisations.
As a bonus add some extra optimisations when the "Zba" extension is available.
ma_mul32 and ma_mul64 don't perform the same optimisations, but that can
be fixed in another bug.
Comment 10•5 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/2c4198280e00
https://hg.mozilla.org/mozilla-central/rev/721231268175
https://hg.mozilla.org/mozilla-central/rev/c6fd398009c9
https://hg.mozilla.org/mozilla-central/rev/253205d0442c
https://hg.mozilla.org/mozilla-central/rev/9caac908dd89
https://hg.mozilla.org/mozilla-central/rev/fadd160656bf
https://hg.mozilla.org/mozilla-central/rev/f25c6543c2cc
https://hg.mozilla.org/mozilla-central/rev/7887e75461cb
https://hg.mozilla.org/mozilla-central/rev/24949d57b331
| Comment hidden (off-topic) |
| Comment hidden (obsolete) |
| Comment hidden (obsolete) |
Updated•5 months ago
|
Comment 14•5 months ago
|
||
Comment on attachment 9589210 [details]
Bug 2041359 - Added support for color swatches for attr() with type(<color>) specification. r=#devtools-reviewers,nchevobbe
Revision D302217 was moved to bug 2040912. Setting attachment 9589210 [details] to obsolete.
Updated•4 months ago
|
Updated•4 months ago
|
Description
•