Bug 141017 - Add a trivial code generator for the DFA
Summary: Add a trivial code generator for the DFA
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Benjamin Poulain
URL:
Keywords:
Depends on: 141757
Blocks:
  Show dependency treegraph
 
Reported: 2015-01-28 16:29 PST by Benjamin Poulain
Modified: 2015-03-21 12:31 PDT (History)
6 users (show)

See Also:


Attachments
Patch (23.75 KB, patch)
2015-01-28 16:30 PST, Benjamin Poulain
no flags Details | Formatted Diff | Diff
Patch (23.74 KB, patch)
2015-01-28 16:53 PST, Benjamin Poulain
kling: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Poulain 2015-01-28 16:29:37 PST
Add a trivial code generator for the DFA
Comment 1 Benjamin Poulain 2015-01-28 16:30:54 PST
Created attachment 245577 [details]
Patch
Comment 2 Benjamin Poulain 2015-01-28 16:53:21 PST
Created attachment 245584 [details]
Patch
Comment 3 Chris Dumez 2015-01-30 15:59:40 PST
Comment on attachment 245584 [details]
Patch

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

I don't feel confident reviewing, someone else should take a look but I made a few (minor) comments.

> Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:141
> +        PotentialPageLoadDescriptor potentialPageLoadDescriptor;

PotentialPageLoadDescriptor potentialPageLoadDescriptor{urlCString.data(), urlCString.length()};

> Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:145
> +        HashSet<unsigned, DefaultHash<unsigned>::Hash, WTF::UnsignedWithZeroKeyHashTraits<unsigned>> triggeredActions;

"TriggeredActionSet triggeredActions;" ?

> Source/WebCore/contentextensions/DFA.h:50
> +    const DFANode& nodeAt(unsigned i) const

nit: Could be on a single line.

> Source/WebCore/contentextensions/DFA.h:59
> +

extra line?

> Source/WebCore/contentextensions/DFACompiler.cpp:48
> +    DFACodeGenerator(const DFA&);

explicit?

> Source/WebCore/contentextensions/DFACompiler.cpp:55
> +    void getNextCharacter(Assembler::JumpList& failureCases, LocalRegister& output);

"get" prefix?

> Source/WebCore/contentextensions/DFACompiler.cpp:64
> +    JSC::MacroAssembler::RegisterID m_urlBufferOffsetRegister = InvalidGPRReg;

Assembler::RegisterID ?

> Source/WebCore/contentextensions/DFACompiler.cpp:140
> +        callAddActionFunction(static_cast<unsigned>(actionId));

Why is this safe?

> Source/WebCore/contentextensions/DFACompiler.cpp:145
> +    for (const auto transition : dfaNode.transitions) {

auto& transition ? It probably doesn't matter for this particular underlying type if we're copying it but I still like to use auto& in range loops. I would omit the const but this may be a matter of taste.
Comment 4 Gavin Barraclough 2015-01-31 16:32:30 PST
Comment on attachment 245584 [details]
Patch

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

> Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:129
> +    reinterpret_cast<TriggeredActionSet*>(data)->add(actionId);

Could we avoid the reinterpret cast by changing the signature of this function & the AddActionFunction typedef?

> Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:140
> +        CString urlCString = urlString.utf8();

Is converting to Cstring efficient here? – may be good to add a fixme & bugzilla number to remember to revisit.
Comment 5 Benjamin Poulain 2015-01-31 18:29:07 PST
(In reply to comment #4)
> > Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:129
> > +    reinterpret_cast<TriggeredActionSet*>(data)->add(actionId);
> 
> Could we avoid the reinterpret cast by changing the signature of this
> function & the AddActionFunction typedef?

Yes, I should do that :)

> > Source/WebCore/contentextensions/ContentExtensionsBackend.cpp:140
> > +        CString urlCString = urlString.utf8();
> 
> Is converting to Cstring efficient here? – may be good to add a fixme &
> bugzilla number to remember to revisit.

I don't expect this to be a big problem. The valid URLS are already ASCII so there is no encoding cost.
Comment 6 Andreas Kling 2015-02-16 20:16:47 PST
Comment on attachment 245584 [details]
Patch

r+ to move this forward, though please consider the feedback given by Gavin & Chris. :-)
Comment 7 Benjamin Poulain 2015-02-18 00:57:53 PST
Committed r180260: <http://trac.webkit.org/changeset/180260>
Comment 8 Joseph Pecoraro 2015-02-18 01:06:27 PST
(In reply to comment #7)
> Committed r180260: <http://trac.webkit.org/changeset/180260>

Seems this broke 32-bit builds?
https://build.webkit.org/builders/Apple%20Yosemite%20Release%20%2832-bit%20Build%29/builds/685
https://build.webkit.org/builders/Apple%20Yosemite%20Release%20%2832-bit%20Build%29/builds/685/steps/compile-webkit/logs/errors

> Source/WebCore/contentextensions/DFACompiler.cpp:55:69: error: unknown type name 'LocalRegister'
> Source/WebCore/contentextensions/DFACompiler.cpp:61:5: error: unknown type name 'RegisterAllocator'
> Source/WebCore/contentextensions/DFACompiler.cpp:62:5: error: unknown type name 'StackAllocator'; did you mean 'JSC::BlockAllocator'?
> Source/WebCore/contentextensions/DFACompiler.cpp:77:7: error: no matching constructor for initialization of 'JSC::BlockAllocator'
Comment 9 WebKit Commit Bot 2015-02-18 09:04:05 PST
Re-opened since this is blocked by bug 141757
Comment 10 Alex Christensen 2015-02-19 12:28:29 PST
This works on ARM64 with the same prolog and epilog as the cssjit.  That code could be shared, but DFACodeGenerator would also need a m_prologueStackReferences.  I imagine it would work on ARMv7, too, but I haven't checked that.
Comment 11 Benjamin Poulain 2015-03-21 12:31:08 PDT
We'll use an interpreter instead.