Closed Bug 939820 Opened 11 years ago Closed 11 years ago

LNop and LLabel are not needed for backtracking register allocator

Categories

(Core :: JavaScript Engine: JIT, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla28

People

(Reporter: sunfish, Assigned: sunfish)

Details

(Whiteboard: [qa-])

Attachments

(3 files)

LNop and LLabel are two instructions which apparently exist to help out with the way that LSRA does liveness. As far as I can tell, the backtracking allocator doesn't need them.

Attached is a patch which moves the Label out of LLabel and into LBlock, which has the nice effect of simplifying the code in CodeGenerator.cpp, and which makes LLabel a completely trivial instruction, just like LNop.

Then, two patches which disable the creation of LLabel and LNop when the register allocator isn't LSRA. Checking the register allocator flag in a bunch of places is a little ugly, but it does make working in the backtracking allocator a little nicer to not have to worry about whether these extra instructions have any special effect.
Comment on attachment 8333879 [details] [diff] [review]
regalloc-trivialize-llabel.patch

This patch is just the change to move the Label out of LLabel and into LBlock, which makes some code in CodeGenerator.cpp a little nicer.
Attachment #8333879 - Flags: review?(bhackett1024)
This patch skips the creation of LLabel when the register allocator is not LSRA. It's a little ugly to be testing for the register allocator everwhere, but it does make debugging the backtracking allocator a little nicer, since there are fewer oddities.
Attachment #8336061 - Flags: review?(bhackett1024)
Same as the previous, but for LNop.
Attachment #8336063 - Flags: review?(bhackett1024)
Comment on attachment 8333879 [details] [diff] [review]
regalloc-trivialize-llabel.patch

Review of attachment 8333879 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit/CodeGenerator.cpp
@@ +2856,5 @@
>          perfSpewer->startBasicBlock(current->mir(), masm);
>  #endif
> +        LInstructionIterator iter = current->begin();
> +
> +        // The first instruction of every block is an LLabel. Skip it.

Maybe point out that label is a nop.  This is purely an optimization, right?
Attachment #8333879 - Flags: review?(bhackett1024) → review+
Comment on attachment 8336061 [details] [diff] [review]
regalloc-skip-llabel.patch

Review of attachment 8336061 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jit/CodeGenerator.cpp
@@ +2860,5 @@
> +        if (js_IonOptions.registerAllocator == RegisterAllocator_LSRA) {
> +            // The first instruction of every block is an LLabel. Skip it.
> +            JS_ASSERT(iter->isLabel());
> +            ++iter;
> +        }

I think it's better to remove this block entirely, actually.  I think we should be cutting reliance on which of these (process-wide) values is active, as they require everything to line up between Ion/Asm.js, main runtime / worker runtimes, and (most importantly) different levels of optimization for individual scripts.
Attachment #8336061 - Flags: review?(bhackett1024) → review+
Attachment #8336063 - Flags: review?(bhackett1024) → review+
(In reply to Brian Hackett (:bhackett) from comment #5)
> Comment on attachment 8336061 [details] [diff] [review]
> regalloc-skip-llabel.patch
> 
> Review of attachment 8336061 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/jit/CodeGenerator.cpp
> @@ +2860,5 @@
> > +        if (js_IonOptions.registerAllocator == RegisterAllocator_LSRA) {
> > +            // The first instruction of every block is an LLabel. Skip it.
> > +            JS_ASSERT(iter->isLabel());
> > +            ++iter;
> > +        }
> 
> I think it's better to remove this block entirely, actually.  I think we
> should be cutting reliance on which of these (process-wide) values is
> active, as they require everything to line up between Ion/Asm.js, main
> runtime / worker runtimes, and (most importantly) different levels of
> optimization for individual scripts.

Makes sense. I removed this block entirely.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f1fb7194cb67
https://hg.mozilla.org/integration/mozilla-inbound/rev/45cb9a81f09e
https://hg.mozilla.org/integration/mozilla-inbound/rev/bd6620d81f76
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: