Hello, Thank you for all these links, they were very useful in understanding Turbofan more. Upon trying stuff more, I think that maybe putting everything (even low-level logic) in bytecode-graph-builder.cc like I was thinking earlier would be starkly different than how the rest of the Visit..Bytecode methods are, and additionally be painful to implement.
Alternatively, I was thinking of a new simplified/VM-level opcode, TryTaggedToWord32, which returns sort of an Optional<Word32>, so in Turbofan it would be a tuple (bool,word32) returned by the opcode, which I could then extract out using projections for the core code in bytecode-graph-builder.cc, I was wondering do you think this would be an ok design? The main part I was having trouble with? 1. How to construct an opcode that returns such a tuple? (I was looking through the codebase, and the only such examples were in js-operator (too high level))? 2. Or maybe should my opcode should really be a machine-op level opcode, similar to TryTruncateFloat64...? Also, I was wondering should I create the PR for this, just so you can view my code so far (or should I hold off until I have a working version?) Thank you so much! On Thursday, August 5, 2021 at 4:02:52 AM UTC-5 [email protected] wrote: > This diagram definitely looks like a plausible solution, if those > lower-level F2I/I2F nodes are available to you at that point (I think they > might be?) -- TF has some amount of restrictions on what "level" of node is > available at what stage of the pipeline. > > As for documentation, we're not in a fantastic state. You might get > something out of the turbofan handbook > <https://docs.google.com/document/d/16WdvJCb7M2nyywDd2Kt7Z8ZB9b9uGtwCywOY1Ga6y0w/edit>, > > and I have an old presentation > <https://docs.google.com/presentation/d/1chhN90uB8yPaIhx_h2M3lPyxPgdPmkADqSNAoXYQiVE/edit#slide=id.g1ba7f92079_0_199> > on > how graph building works in general, but sadly can't find a recording of > it. The general idea is that it's roughly a symbolic execution of the > bytecode, with the "environment" representing the current state of the > execution (including current control nodes, current register values, etc.). > If you want to branch the execution, you have to copy the current > environment, if you want to switch to another execution branch you have to > set the current environment, and if you want to merge two branches you have > to merge their environments. "SubEnvironment" is a helper for copying and > setting the current environment, but it's not strictly necessary to use it. > > For your case, with two branches, you could have something like > > Environment* after; > { > SubEnvironment sub(this); > NewIfTrue(); > ... > after = environment() > set_environment(nullptr); > } > { > SubEnvironment sub(this); > NewIfFalse(); > ... > after = after->Merge(environment(), /* probably need the current > bytecode's liveness here, see other uses of Merge */) > set_environment(nullptr); > } > set_environment(after); > > > On Thu, Aug 5, 2021 at 7:49 AM Mihir Shah <[email protected]> wrote: > >> Hello, >> >> I followed up with the cc'ed recipients from last message, but I think it >> may be going to their spam, since I'm not sending from a Google/Chromium >> address. >> >> I was thinking, instead of using a new opcode (I'm not sure, but I think >> this could require making a lot of changes all across the codebase, since >> so many optimizations switch on the opcode type, etc.), could we implement >> everything in bytecode-graph-builder.cc? >> >> Attached is the sea-of-nodes graph I was visualizing for the method: >> >> https://drive.google.com/file/d/1HS2YBxJXYQ8SFiFcO8f9lhR5UVouN06Z/view?usp=sharing >> >> >> So far, I wasn't sure mainly, >> 1. How do merges and branches work in the code? Because in a lot of the >> code I see branches as >> >> NewBranch(...) >> { >> SubEnvironment... >> BuildJumpIfFalse... >> ... >> MergeIntoSuccessorOffset(int offset) or MergeLeaveFunction >> } >> BuildJumpIfTrue... >> >> But since the merging I want is between two nodes, neither of these kind >> of merges I think would apply. I was thinking of using MergeControl, but >> this doesn't seem to jive well with the scoping here. I was also wondering, >> would I have to do anything with the environment() as well? >> >> Finally, I was wondering if there is more documentation on the >> bytecode-graph-builder.cc code, at this more granular level of these >> methods, outside of v8.dev/docs/turbofan (so I can understand it >> better?) >> >> Thank you so much! >> >>> >>>> -- >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev >> --- >> You received this message because you are subscribed to the Google Groups >> "v8-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/6978b552-c40c-4bcb-a456-86963475e1cbn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/6978b552-c40c-4bcb-a456-86963475e1cbn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/b0c01f2d-7ce6-4033-8d0f-0b0e3dd77024n%40googlegroups.com.
