The runtime approach w/ inline assembly sounds fine as a starting point. Maybe we can kill FCG and CS this year, and then we can reconsider a TF only solution (the interpreter handlers are also TF based)
-- Benedikt Ben Smith <bi...@chromium.org> schrieb am Di., 29. Dez. 2015, 22:35: > On Thursday, December 17, 2015 at 2:17:01 PM UTC-8, Ben Smith wrote: >> >> >> >> On Thursday, December 17, 2015 at 11:26:48 AM UTC-8, Benedikt Meurer >> wrote: >>> >>> Can't you use the same instruction sequence, even from C++ code? >>> >> >> Yeah, I could, just not using the compiler intrinsics. I was hoping to >> avoid duplicating the sequence in multiple locations, but it might be the >> best way. >> >> >>> Or compile a small stub that is callable from C++ directly and thereby >>> use the same instruction sequence? >>> >> >> Right, this way makes the most sense to me. >> > > OK, I've investigated this some more and have some more questions: > > The Atomics functions are polymorphic over the different TypedArray types > (similar to ArrayBuffer keyed property access). So currently the functions > check the TypedArray base type and forward to the current atomic > instruction for that type. But TurboFan for asm.js should have enough type > information to determine the correct TypedArray type without this check, so > it makes sense that the codestubs should not have this check. > > So assuming we have codestubs like AtomicLoad8, AtomicLoad16, etc. how can > I call these from FCG? It looks like the current way code stubs are called > in FCG is via intrinsics (e.g. Math.pow or String.fromCharCode). But if I > am hooking to the JavaScript functions then I'll have to match Atomics.load > first, then do the TypedArray check in the FCG compiler so I can forward to > the correct codestub. Looks like it should work, but I'm wondering if it is > the right way to do things. It seems like the current path uses a type > feedback in an IC to handle this, though that seems like a lot more work, > and AFAICT won't be optimized without CS anyway, is that correct? > > And speaking of CrankShaft, doesn't implementing the type check in FCG > require me to do the same check in CS? Or is there a way to share this code > between the two? > > Thinking through it more, perhaps the best solution is to use inline > assembly in the runtime functions. Inline assembly doesn't seem to be used > much in v8 (mostly just the atomics implementations borrowed for Chromium), > but it would really simplify the code here: I could use the same runtime > functions I'm using now for FCG and CS, then have TF generate the same > instruction sequence. The biggest drawback is that keeping the instruction > sequences the same would have to be maintained manually. > > What do you think? > > >> >> >>> Also the code stub should work if that's being used by CS and FCG, while >>> you can inline the code into TF. You just need to make sure to generate the >>> exactly the same instructions I guess? >>> >> >> Yeah, I suppose inlining the TF can be a later optimization if desired. >> >> >>> IIRC Jaro thought about this already, maybe he can give some advice. >>> >>> On Thu, Dec 17, 2015 at 8:06 PM, Ben Smith <bi...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wednesday, December 16, 2015 at 7:16:07 PM UTC-8, Benedikt Meurer >>>> wrote: >>>>> >>>>> You probably need the same guarantees for CS. So how about putting >>>>> them into a code stub? And calling the stub for the %_ cases in all three >>>>> compilers? >>>>> >>>> >>>> Yes, that's what I was thinking too, but I was wondering if there was >>>> another way -- AIUI the code stub has the overhead of a function call for >>>> all compilers, right? >>>> >>>> >>>>> BTW wouldn't it work if FCG always uses the C++ version? >>>>> >>>> >>>> Maybe I'm misunderstanding when the various compilers are used. But if >>>> it's possible that some code that was compiled with FCG is being used at >>>> the same time that compiled with TF is used and they are accessing the same >>>> shared memory, then it's necessary that they have the same instruction >>>> sequence. >>>> >>>> >>>>> -- Benedikt >>>>> >>>>> Ben Smith <bi...@chromium.org> schrieb am Do., 17. Dez. 2015, 00:01: >>>>> >>>>>> Hi v8-dev, >>>>>> >>>>>> I added the Atomics API earlier this year (in >>>>>> src/js/harmony-atomics.js and src/runtime/runtime-atomics.cc). It's >>>>>> currently implemented as runtime functions using compiler intrinsics. I'd >>>>>> like to add a TurboFan implementation, but I need to make sure that the >>>>>> generated assembly is the same in both the full-codegen and for TF. >>>>>> What's >>>>>> the best way to do this? >>>>>> >>>>>> FYI, here's the associated bug: >>>>>> https://bugs.chromium.org/p/v8/issues/detail?id=4614 >>>>>> >>>>>> Thanks, >>>>>> -Ben >>>>>> >>>>>> -- >>>>>> -- >>>>>> v8-dev mailing list >>>>>> v8-...@googlegroups.com >>>>>> 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 v8-dev+un...@googlegroups.com. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> -- >>>> v8-dev mailing list >>>> v8-...@googlegroups.com >>>> 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 v8-dev+un...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > 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 v8-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list v8-dev@googlegroups.com 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 v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
