New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 617073 link

Starred by 1 user
Status: Assigned
Owner:
danno@chromium.org
Cc:
jkummerow@chromium.org
verwa...@chromium.org
ishell@chromium.org
█ epertoso@chromium.org
danno@chromium.org
bmeu...@chromium.org
jarin@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature



Sign in to add a comment

Fine grained control over the block order generated by CodeStubAssembler

Project Member Reported by ishell@chromium.org, Jun 3 2016 
I think we need more fine grained control over the block order generated by CodeStubAssembler.

It would be enough useful if it could respect the order of Label bindings in the source code.


Alternative approach could be to split kNonDeferred to kLikely and kUnlikely.

Branch(..., kLikely, kLikely) should generate diamond.
Branch(..., kLikely, kUnlikely) should generate a fall through to likely block.

Comment 1 by danno@chromium.org, Jun 3 2016 

I am not what you'd like to accomplish that is not already possible with the existing interface. In the "unlikely" case, this is just deferred code, and the kDeferred label should already take care of this. In the case that you want a diamond, you should already get one, but note that it's probably important to bind the code labels in the right order and pass them in the right order to the Branch operator, i.e. the first label in the Branch instruction is the "taken" patch, so the non-taken label--the second one--should be the one Bound immediately after the Branch for. However, it's my understanding that Jump threading, which runs on CSA code, should try to flatted branch tangles almost as well as you can by hand, 

Can you please provide a specific example of the CSA code that isn't generated what you'd like?

Comment 2 by ishell@chromium.org, Jun 3 2016 

In https://codereview.chromium.org/2031753003/ the CodeStubAssembler::LoadIC() has a label {if_handler} which I expected to appear exactly after the TryMonomorphicCase() but it went to the very end of the stub.

See the code of LoadICTrampolineTFStub, for example.

Comment 3 by bmeu...@chromium.org, Jun 21 2016

Labels: -Type-Bug OS-All Type-Feature
Owner: danno@chromium.org
►

Sign in to add a comment