Bug 115576 - There should be a runtime option to constrain what functions get DFG compiled
Summary: There should be a runtime option to constrain what functions get DFG compiled
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Michael Saboff
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-03 15:38 PDT by Michael Saboff
Modified: 2013-05-04 00:54 PDT (History)
1 user (show)

See Also:


Attachments
Patch (6.75 KB, patch)
2013-05-03 15:58 PDT, Michael Saboff
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Saboff 2013-05-03 15:38:07 PDT
Often when debugging a problem in the DFG, one wants to constrain DFG compilation down to one function.  Usually this can be done by checking the bytecode count of the code block by adding an if statement at the top of compile() in DFGDriver.cpp.  This should be done through an runtime option.
Comment 1 Michael Saboff 2013-05-03 15:58:38 PDT
Created attachment 200504 [details]
Patch
Comment 2 WebKit Commit Bot 2013-05-03 16:00:13 PDT
Attachment 200504 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/JavaScriptCore/ChangeLog', u'Source/JavaScriptCore/dfg/DFGDriver.cpp', u'Source/JavaScriptCore/runtime/Options.cpp', u'Source/JavaScriptCore/runtime/Options.h']" exit_code: 1
Source/JavaScriptCore/runtime/Options.h:220:  enum members should use InterCaps with an initial capital letter.  [readability/enum_casing] [4]
Total errors found: 1 in 4 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Mark Hahnenberg 2013-05-03 18:48:46 PDT
Comment on attachment 200504 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=200504&action=review

r=me with comments.

> Source/JavaScriptCore/runtime/Options.cpp:75
> +static bool parse(const char* string, optionRange& value)

Does it work correctly if you use OptionRange& here instead of the typedef? I know there are some subtleties with how the macros automatically generate stuff, but I dislike how this looks.
Comment 4 Michael Saboff 2013-05-03 21:23:42 PDT
(In reply to comment #3)
> (From update of attachment 200504 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=200504&action=review
> 
> r=me with comments.
> 
> > Source/JavaScriptCore/runtime/Options.cpp:75
> > +static bool parse(const char* string, optionRange& value)
> 
> Does it work correctly if you use OptionRange& here instead of the typedef? I know there are some subtleties with how the macros automatically generate stuff, but I dislike how this looks.

We can use OptionRange& here.  The typedef was put in so the enum and union type work with the FOR_EACH_OPTION macros.
Comment 5 Michael Saboff 2013-05-04 00:53:45 PDT
Comment on attachment 200504 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=200504&action=review

>>> Source/JavaScriptCore/runtime/Options.cpp:75
>>> +static bool parse(const char* string, optionRange& value)
>> 
>> Does it work correctly if you use OptionRange& here instead of the typedef? I know there are some subtleties with how the macros automatically generate stuff, but I dislike how this looks.
> 
> We can use OptionRange& here.  The typedef was put in so the enum and union type work with the FOR_EACH_OPTION macros.

We can use OptionRange here.  The typedef was put in for the enum and type within the union.
Comment 6 Michael Saboff 2013-05-04 00:54:30 PDT
Clearing flags on attachment: 200504

Committed r149552: <http://trac.webkit.org/changeset/149552>
Comment 7 Michael Saboff 2013-05-04 00:54:53 PDT
All reviewed patches have been landed.  Closing bug.