Skip to content

Cmake #1

wants to merge 5 commits into from

2 participants


So for some reason I did not manage to figure out the supplemental idl deps file generated by the cmake build is more complete than the one we generate in our autotools build. Some relationships only appear in the cmake one, and thus the additional #ifdefing was required where I did not want to include the idl file in the list.


Nice stuff! I'm splitting apart the current patch (some of it has already landed), but hopefully I can rebase your work on top of my new branch.

@mrobinson mrobinson pushed a commit that referenced this pull request Sep 9, 2013 fourthTier: DFG Nodes should be able to abstractly tell you what they…
… read and what they write


Reviewed by Sam Weinig.

Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in
the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are
engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to
be inexpensive to use (they just give you a TBAA node) but expensive to create (you
create them all up front). FTL AbstractHeaps also don't actually give you the
ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA.
The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use.
They also give you aliasing machinery. The DFG AbstractHeaps are represented
internally by a int64_t. Many comparisons between them are just integer comaprisons.
AbstractHeaps form a three-level hierarchy (World is the supertype of everything,
Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP
payload is the direct subtype of its corresponding TOP Kind).

Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had
clobbered. It represents the set that results from unifying a bunch of
AbstractHeaps, and is intended to quickly answer overlap questions: does the given
AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an
AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of
its ancestors. An AbstractHeap is said to overlap a set if any direct or super
member is equal to it, or if any of its ancestors are equal to a direct member.

Example #1:

    - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This
      is a subtype of Variables, which is a subtype of World.
    - You query Variables. I.e. Variables with a TOP payload, which is the
      supertype of Variables(X) for any X, and a subtype of World.

    The set will have Variables(5) as a direct member, and Variables and World as
    super members. The Variables query will immediately return true, because
    Variables is indeed a super member.

Example #2:

    - I add Variables(5)
    - You query NamedProperties

    NamedProperties is not a member at all (neither direct or super). We next
    query World. World is a member, but it's a super member, so we return false.

Example #3:

    - I add Variables
    - You query Variables(5)

    The set will have Variables as a direct member, and World as a super member.
    The Variables(5) query will not find Variables(5) in the set, but then it
    will query Variables. Variables is a direct member, so we return true.

Example #4:

    - I add Variables
    - You query NamedProperties(5)

    Neither NamedProperties nor NamedProperties(5) are members. We next query
    World. World is a member, but it's a super member, so we return false.

Overlap queries require that either the heap being queried is in the set (either
direct or super), or that one of its ancestors is a direct member. Another way to
think about how this works is that two heaps A and B are said to overlap if
A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a
single-inheritance heirarchy. Consider that we wanted to implement a set that holds
heaps and answers the question, "is any member in the set an ancestor (i.e.
supertype) of some other heap". We would have the set contain the heaps themselves,
and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor
chain of A, and repeatedly querying its membership in the set. This is what the
"direct" members of our set do. Now consider the other part, where we want to ask if
any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We
would implement this by implementing set.add(B) as adding not just B but also all of
B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is
in the set. With two such sets - one that answers isSubtypeOfAny() and another that
answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your
heap" question. ClobberSet does this, but combines the two sets into a single
HashMap. The HashMap's value, "direct", means that the key is a member of both the
supertype set and the subtype set; if it's false then it's only a member of one of

Finally, this adds a functorized clobberize() method that adds the read and write
clobbers of a DFG::Node to read and write functors. Common functors for adding to
ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers
are also provided. This allows you to say things like:

    ClobberSet set;
    addWrites(graph, node1, set);
    if (readsOverlap(graph, node2, set))
        // We know that node1 may write to something that node2 may read from.

Currently this facility is only used to improve graph dumping, but it will be
instrumental in both LICM and GVN. In the future, I want to completely kill the
NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way
of accomplishing almost exactly what AbstractHeap gives you.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractHeap.cpp: Added.
* dfg/DFGAbstractHeap.h: Added.
* dfg/DFGClobberSet.cpp: Added.
* dfg/DFGClobberSet.h: Added.
* dfg/DFGClobberize.cpp: Added.
* dfg/DFGClobberize.h: Added.
* dfg/DFGGraph.cpp:


Reviewed by Sam Weinig.

Fix compile goof in sortedListDump().

* wtf/ListDump.h:


git-svn-id: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@mrobinson mrobinson pushed a commit that referenced this pull request Sep 10, 2013 Unreviewed, don't rely on File::Slurp. This fixes part #1 of Linux bo…
…t breakage.

* Scripts/run-javascriptcore-tests:

git-svn-id: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@mrobinson mrobinson pushed a commit that referenced this pull request Dec 9, 2013 Be explicit about backwards propagation properties that care about es…
…caping to bytecode, as opposed to just escaping within DFG code.

Rubber stamped by Mark Hahnenberg.
We need to care about escaping to bytecode if we're doing a lossy optimization,
i.e. the optimization means we produce less information and so we can't rescue
ourselves during OSR exit.
We only need to care about escaping within the DFG code (and can ignore what
might happen in bytecode) if we're doing an optimization that is lossless, i.e.
we can always still reconstruct the values that bytecode wants.
Example #1:
    Large int32 + int32 which overflows. We want to optimize away the overflow
    check and just do a 32-bit add.
    This is lossy; the result should have one extra bit but we simply throw
    that bit away by doing a check-less 32-bit add. Hence we need to know that 
    even the bytecode wouldn't have cared about that bit. This is true in cases
    like (a + b) | 0.
Example #2:
    Larbe int32 + int32 which overflows. We want to optimize away the overflow
    check by doing a 64-bit add.
    This is lossless. We can always convert the resulting 64-bit int back to a
    double if that's what bytecode wants. Hence we only need to know that the
    DFG code won't want to do something to this value that would make 64-bit
    ints either unprofitable or unsound.
The backwards propagator's notions of flags (NodeUsedAsValue, etc) are for lossy
optimizations and so should be named in a way that reflects this. This patch
calls then NodeBytecodeUsesAsValue, etc.
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGArrayMode.cpp:
* dfg/DFGBackwardsPropagationPhase.cpp:
* dfg/DFGFixupPhase.cpp:
* dfg/DFGGraph.h:
* dfg/DFGNode.h:
* dfg/DFGNodeFlags.cpp:
* dfg/DFGNodeFlags.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
* dfg/DFGVariableAccessData.h:
* ftl/FTLLowerDFGToLLVM.cpp:

git-svn-id: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@mrobinson mrobinson pushed a commit that referenced this pull request Dec 9, 2013 It should be easy to add new nodes that do OSR forward rewiring in bo…
…th DFG and FTL

Reviewed by Sam Weinig.
Forward rewiring is a tricky part of OSR that handles the following:
    a: Something(...)
       SetLocal(@a, locX)
    b: Int32ToDouble(@a)
    c: SomethingThatExits(@b)
       <no further uses of @a or @b>

Note that at @c, OSR will think that locX->@a, but @a will be dead. So it must be
smart enough to find @b, which contains an equivalent value. It must do this for
any identity functions we support. Currently we support four such functions.
Currently the code for doing this is basically duplicated between the DFG and the
FTL. Also both versions of the code have some really weirdly written logic for
picking the "best" identity function to use.
We should fix this by simply having a way to ask "is this node an identity
function, and if so, then how good is it?"  Then both the DFG and FTL could use
this and have no hard-wired knowledge of those identity functions.
While we're at it, this also changes some terminology because I found the use of
the word "needs" confusing. Note that this retains the somewhat confusing behavior
that we don't search all possible forward/backward uses. We only search one step
in each direction. This is because we only need to handle cases that FixupPhase
and the parser insert. All other code that tries to insert intermediate conversion
nodes should ensure to Phantom the original node. For example, the following
transformation is illegal:
    x: SomethingThatExits(@a)
    w: Conversion(@a)
    x: SomethingThatExits(@w)
The correct form of that transformation is one of these:
Correct #1:
    v: DoAllChecks(@a) // exit here
    w: Conversion(@a)
    x: Something(@w) // no exit
Correct #2:
    w: Conversion(@a)
    x: SomethingThatExits(@w)
    y: Phantom(@a)
Correct #3:
    w: Conversion(@a)
    x: SomethingThatExits(@w, @a)
Note that we use #3 for some heap accesses, but of course it requires that the
node you're using has an extra slot for a "dummy" use child.
Broadly speaking though, such transformations should be relegated to something
below DFG IR, like LLVM IR.

* dfg/DFGNodeType.h:
* dfg/DFGVariableEventStream.cpp:
* ftl/FTLLowerDFGToLLVM.cpp:

git-svn-id: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@mrobinson mrobinson pushed a commit that referenced this pull request Dec 9, 2013 Scrollbars are updated on the main thread rather than the scrolling t…

(causing scroll bars not to appear/update quickly in some cases)
-and corresponding-

Reviewed by Simon Fraser.


This patch does a few things in order to allow scrollbars to be updated on the 
scrolling thread:

1. This patch adds the ability to know if the lower-level APIs necessary to get 
this to work right are available, AND if the content is actually capable of taking 
advantage of this feature. This is currently implemented as 
Scrollbar::supportsUpdateOnSecondaryThread() which makes use of a new 
ScrollableArea function called updatesScrollLayerPositionOnMainThread()
2. To update on the scrolling thread, the scrolling tree needs to know about the 
3. Once it knows about them, it should update the presentation value whenever the 
layer position changes.
4. Presentation value is basically the same thing as double value. There is a bit 
of code we maintain currently to compute that. This patch moves that code to a 
static function on ScrollableArea that can be called from both the main thread and 
the scrolling thread.
5. ScrollbarPainter API needs to know about the layers we have created for the 
vertical and horizontal scrollbars, then they will use those layers and the 
presentation value that we set on the scrolling thread to move the layers around.

This is part of #1 above. 
* page/FrameView.cpp:
* page/FrameView.h:

This is part of #2. ScrollingStateScrollingNodes now have vertical and horizontal 
ScrollbarPainters for Mac only.
* page/scrolling/ScrollingStateScrollingNode.cpp:
* page/scrolling/ScrollingStateScrollingNode.h:

Also part of #2. Make sure to set the ScrollbarPainters for scrolling nodes when 
* page/scrolling/mac/ScrollingCoordinatorMac.h:
* page/scrolling/mac/

Implement this function that was just stubbed out before. This is part of #5 in 
that is will allow the ScrollbarPainter API to know about any layer changes. 

Back to #2, making sure we properly set the ScrollbarPainters to send over to the 
scrolling thread.
* page/scrolling/mac/

This code achieves #3. It uses new ScrollbarPainter API to adjust the position of 
the scrollbars from the scrolling thread.
* page/scrolling/mac/ScrollingTreeScrollingNodeMac.h:
* page/scrolling/mac/

This is for #5. ScrollbarPainter needs to know about our scrollbar layers.
* platform/ScrollAnimator.h:
* platform/ScrollableArea.cpp:

This is for #4. This code computes the scrollbar’s value and current overhang 
* platform/ScrollableArea.h:

This is for #1. We need to know if we have the ability to update scrollbars on a 
different thread. We can do that only on certain versions of the OS, only when 
threaded scrolling is enabled, and only when the current page is actually using 
the scrolling thread to scroll.
* platform/Scrollbar.cpp:
* platform/Scrollbar.h:
* platform/ScrollbarThemeClient.h:

New ScrollbarPainter APIs.
* platform/mac/NSScrollerImpDetails.h:

This is for #5, letting the ScrollbarPainter API  know about the layers.
* platform/mac/ScrollAnimatorMac.h:
* platform/mac/
(-[WebScrollbarPainterDelegate layer]):
(-[WebScrollbarPainterDelegate convertRectToLayer:]):
(-[WebScrollbarPainterDelegate shouldUseLayerPerPartForScrollerImp:]):

Before we kick off a scroll animation, set the current painting characteristics so 
they are up-to-date in case we are scrolling on the scrolling thread.
(-[WebScrollbarPainterDelegate setUpAlphaAnimation:scrollerPainter:part:WebCore::animateAlphaTo:duration:]):
(-[WebScrollbarPainterDelegate scrollerImp:animateKnobAlphaTo:duration:]):
(-[WebScrollbarPainterDelegate scrollerImp:animateTrackAlphaTo:duration:]):

Only paint the scrollbars through ScrollbarThemeMac if they are NOT being updated 
by the scrolling thread.
* platform/mac/ScrollbarThemeMac.h:
* platform/mac/

Back to #1.
* rendering/RenderLayer.cpp:
* rendering/RenderLayer.h:
* rendering/RenderLayerCompositor.cpp:
* rendering/RenderListBox.h:


New pure virtual function.
* WebProcess/Plugins/PDF/PDFPlugin.h:

git-svn-id: 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@mrobinson mrobinson closed this Dec 20, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.