I have a CL for this now: https://codereview.chromium.org/1550803006/. It only implements inline assembly for x64/ia32 for now, and uses a separate asm source file for x64 on msvc.
On Tuesday, January 5, 2016 at 12:11:11 PM UTC-8, Ben Smith wrote: > > 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> 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 >>> 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.
