Thanks for sending this. There are some really interesting results here. For instance in StackCheck, TF generates this sequence: 0x4560805c 1c e30f903d movw r9, #61501 0x45608060 20 e34f9fff movt r9, #65535 0x45608064 24 e08a9009 add r9, r10, r9 0x45608068 28 e5999000 ldr r9, [r9, #+0]
where LLVM generates: 0x455f61fc 1c e51a0fc3 ldr r0, [r10, #-4035] This is definitely something we could do better in TF. We did notice some problems though in the generated code. For SetPendingMessage, TF generates: 0x45608140 0 e30015f1 movw r1, #1521 0x45608144 4 e08a1001 add r1, r10, r1 0x45608148 8 e5913000 ldr r3, [r1, #+0] 0x4560814c c e5810000 str r0, [r1, #+0] 0x45608150 10 e2855001 add r5, r5, #1 0x45608154 14 e7d61005 ldrb r1, [r6, +r5] 0x45608158 18 e7982101 ldr r2, [r8, +r1, lsl #2] 0x4560815c 1c e1a00003 mov r0, r3 0x45608160 20 e12fff12 bx r2 0x45608164 24 e1a00000 mov r0, r0 whereas LLVM generates: 0x455f62c0 0 e2855001 add r5, r5, #1 0x455f62c4 4 e58a05f1 str r0, [r10, #+1521] 0x455f62c8 8 e7d60005 ldrb r0, [r6, +r5] 0x455f62cc c e7981100 ldr r1, [r8, +r0, lsl #2] 0x455f62d0 10 e59a05f1 ldr r0, [r10, #+1521] 0x455f62d4 14 e12fff11 bx r1 Again, this highlights how TF is not generating the most efficient instruction sequences for loads, but it looks like there's a problem in the LLVM code. It's loading into the accumulator (r0) the value it has just stored there, which means the accumulator will be unchanged as a result of this bytecode, but if you look at the original source <https://cs.chromium.org/chromium/src/v8/src/interpreter/interpreter-generator.cc?l=2888&rcl=d99c746bc0886ddb1c119ceb1108aa1098aafee7>, SetPendingMessage sets the accumulator to previous pending message. This is what happens in the TF case. Dan On Sun, 12 Jan 2020 at 23:51, <manjian2...@gmail.com> wrote: > Hi Dan, > Here it is. > And both disable the untrusted code migitation. > > > 在 2020年1月10日星期五 UTC+8下午6:54:27，Dan Elphick写道： >> >> These results look very impressive. Do you think you could post the >> generated assembly code for something simple like StackCheck with and >> without llvm generation? I wonder if it's improving the stack check itself >> of the dispatch. >> >> Thanks, >> Dan >> >> On Fri, 10 Jan 2020 at 00:21, <manji...@gmail.com> wrote: >> >>> [image: 2020-01-09 17-56-56 的屏幕截图.png] >>> >>> [image: 2020-01-09 17-59-12 的屏幕截图.png] >>> Here's the profiler output when I test the following test on a Huawei >>> 荣耀9 cell phone, the v8 version is 7.8: >>> <body> >>> <script> >>> (function() { >>> let a = []; >>> let i; >>> let t0 = performance.now(); >>> for (i = 0; i < 0x1000000; ++i) { >>> a.push(i); >>> } >>> let t1 = performance.now(); >>> console.log('time: ' + (t1 - t0)); >>> })() >>> </script> >>> </body> >>> >>> I feel glad to see the LdaNamedProperty has the amazing improvment, >>> which is my original optimize target. >>> The compiler working on 7.8 version is pretty stable now, I have fixed >>> many bugs these days. >>> >>> 在 2019年11月21日星期四 UTC+8上午8:02:34，manji...@gmail.com写道： >>>> >>>> Hi, >>>> I am working on a new code generator that based on LLVM, and >>>> generate code for both V8 built-ins and WebAssembly. >>>> I try to compile the libffmpeg for video decoder, and find out 50% >>>> and more time reduction. Mainly because LLVM supports auto vectorize. >>>> This project only support arm32 android for now. >>>> Anyone feel interested may checkout the source from >>>> https://github.com/linzj/llvm-toy. And switch to the branch named >>>> arm-tf-7_8_279_17_725bcedcb69 >>>> <https://github.com/linzj/llvm-toy/tree/arm-tf-7_8_279_17_725bcedcb69>. >>>> The hash at the end is the git commit hash. >>>> >>> -- >>> -- >>> 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-...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/68666882-6e5c-478f-b067-4eb140c403da%40googlegroups.com >>> <https://groups.google.com/d/msgid/v8-dev/68666882-6e5c-478f-b067-4eb140c403da%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/70cc42d0-1ee6-4448-8e16-2bcafcfefaf9%40googlegroups.com > <https://groups.google.com/d/msgid/v8-dev/70cc42d0-1ee6-4448-8e16-2bcafcfefaf9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CALH_77vFPh8%3Dd2vn%3DqoApZpu0CQ5wRMVh%3DDgXVEkrfWa_95JBQ%40mail.gmail.com.
