Closed Bug 818480 Opened 12 years ago Closed 12 years ago

BaselineCompiler: Add fast GETGNAME stub

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Assigned: jandem)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

      No description provided.
Attached patch PatchSplinter Review
Later we may also want to use this stub for a GETPROP accessing a dynamic slot. Main problem is that for GETGNAME the input is an unboxed object and for GETPROP we will first have to type check and unbox it. We can encode this in the key, but since these stubs are pretty straight-forward keeping them separate may be simpler.
Attachment #688796 - Flags: review?(kvijayan)
Comment on attachment 688796 [details] [diff] [review]
Patch

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

::: js/src/ion/BaselineIC.cpp
@@ +1002,5 @@
>  
> +// Attach an optimized stub for a GETGNAME/CALLGNAME op.
> +static bool
> +TryAttachGlobalNameStub(JSContext *cx, HandleScript script, ICGetName_Fallback *stub,
> +                        HandleObject global, HandlePropertyName name)

I'm modifying the TypeMonitor_Fallback stub's addMonitorStubForValue to check for existing stubs, so it's safe to call it with the value that this optimized IC stub is being created for, priming the type monitor chain without resorting to an extra call to it later.
Attachment #688796 - Flags: review?(kvijayan) → review+
Ignore that review comment.  It's actually faster and better to use the IC itself to check whether to add new stubs instead of priming it when adding new stubs.
https://hg.mozilla.org/projects/ionmonkey/rev/7d541fb545e2
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: