Closed Bug 1079231 Opened 5 years ago Closed 5 years ago

Use templated CallNonGenericMethod whenever possible

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bbouvier, Assigned: bbouvier)

Details

Attachments

(1 file)

There are several places where we know at compile time what are the arguments for CallNonGenericMethod, but we still pass them as (non-template) runtime parameters. Not sure it really matters, but that looks good for consistency.
That's all the places I could find with DXR.
Attachment #8501031 - Flags: review?(jorendorff)
Comment on attachment 8501031 [details] [diff] [review]
Use templated CallNonGenericMethod whenever possible

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

All right.
Attachment #8501031 - Flags: review?(jorendorff) → review+
The SharedTypedArrayObject hit is probably going to make b2g-ics burn, for what it's worth.  The templated form forces interpretation of the parameters as constants, and gcc < 4.6 manages to bust itself using template-dependent functions as constants somehow.  (The right fix is to add %SharedTypedArray% paralleling %TypedArray%, but that was a bridge much further than I wanted to go just to get %TypedArray% landed.)
Backed out for build failures on b2g-emulator. I was just submitting this patch as i was reading along the code, but this isn't really needed and won't provide obvious speedups, so i propose to just forget about all of this, unless somebody is willing to fight these silly issues.

https://hg.mozilla.org/integration/mozilla-inbound/rev/62491e20145f
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #4)
> The SharedTypedArrayObject hit is probably going to make b2g-ics burn, for
> what it's worth.  The templated form forces interpretation of the parameters
> as constants, and gcc < 4.6 manages to bust itself using template-dependent
> functions as constants somehow.  (The right fix is to add %SharedTypedArray%
> paralleling %TypedArray%, but that was a bridge much further than I wanted
> to go just to get %TypedArray% landed.)

Fun, the first errors that got triggered actually were in the RegExp files...
You need to log in before you can comment on or make changes to this bug.