FYI, another wrinkle: MSVC doesn't support inline assembly for x64 targets <https://msdn.microsoft.com/en-us/library/wbk4z78b.aspx>. :-|
Sounds like the suggested workaround is intrinsics or using the assembler directly. On Monday, January 4, 2016 at 7:18:01 PM UTC-8, Benedikt Meurer wrote: > > Hm, skipping those tests in the simulators could easily backfire. Let's > just do the runtime function approach and see how far we can get. > > -- Benedikt > > Ben Smith <bi...@chromium.org <javascript:>> schrieb am Mo., 4. Jan. > 2016, 22:05: > >> >> >> On Tuesday, December 29, 2015 at 9:07:15 PM UTC-8, Benedikt Meurer wrote: >>> >>> 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 >>> >> >> Another complication here: none (?) of the simulators seem to handle the >> sync/atomic instructions. AFAICT, this should be fine as long as we're >> using the runtime functions w/ inline assembly, but as soon as TF generates >> those instructions they'll need to be handled. They'll also need to be >> somehow translated into the equivalent host sync/atomic instructions, if it >> is possible to be executing an Atomic runtime function at the same time as >> a TF compiled function. >> >> This is probably more trouble than it's worth, though. Maybe the best >> solution is to skip tests that need threads when running via the simulator? >> >> >>> >>> 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-...@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 <javascript:> >> 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 <javascript:>. >> 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.
