Hi, It seems my previous reply to Emanuel didn't send... Basically, I have enabled wasm unrolling in LLVM to help mitigate this already, and I have modified the TS unroller to help improve compile time, and performance, so I'd like to avoid increasing code size.
With respect to figuring out whether a loop iteration takes a long time, what is the upper bound for interrupt latency? If we have an inner loop, without calls, I would assume we could have a reasonable number of instructions and iterations before that latency would be adversely affected? The runtime patching certainly sounds interesting, if more complicated that a loop transform. I had no idea what you were talking about though :) but Pierre has filled me in. I was wondering if patching would be completely necessary, could we not just always have a probing load in the loop? Cheers, Sam On Friday, June 13, 2025 at 8:25:30 AM UTC+1 dmerc...@google.com wrote: > Hi Sam, > > Just so that everybody is on the same page: these stack checks are really > interrupt checks rather than stack-overflow checks or something like that. > > And yea, performing them on every loop iteration is a bit of a waste of > time, but we kinda need them in every loop where we can't prove that the > loop won't run forever (or even: where we can't prove that the loop won't > run for a long time). There is already a mechanism in place in Turboshaft > to try to estimate the number of iterations of specific loops, and then > remove stack checks based on this, cf LoopStackCheckElisionReducer, whose > analysis is done by LoopUnrollingAnalyzer in the LoopUnrollingPhase. > However, as I write this, I'm noticing that the Wasm pipeline doesn't use > the LoopStackCheckElisionReducer outside of loop unrolling (and loop > unrolling only runs if there is at least one small(ish) inner loop). So, it > would make sense to put a LoopStackCheckElisionReducer in the next phase > after LoopUnrollingPhase: WasmGCOptimizePhase... except that this phase > only runs for WasmGC. Maybe we can tweak a little bit the > LoopStackCheckElisionReducer to put it in both WasmGCOptimizePhase > and WasmLoweringPhase (the next phase, which runs unconditionally), but it > would be a nop in WasmLoweringPhase if it has already ran > in LoopStackCheckElisionReducer. > Additional limitation of > LoopUnrollingAnalyzer+LoopStackCheckElisionReducer: the > LoopUnrollingAnalyzer only detects the number of iterations of very > specific loops (something like "for (i = <constant>; i <comparison > operation> <constant>; i += <constant>)"). But it's perfectly reasonable to > improve the pattern matching there to support more loops. > > Another way to improve these interrupt checks that we've talked about > before would be to remove all loop stack checks, and patch the code > in-place when we have an interrupt to trigger. This way, we wouldn't have > to keep repeating those stack checks that most of the time don't do > anything. Probably not super trivial to implement, but doable I would > think. If you want to go down that route, I suggest writing a design doc > and gathering approvals from V8 folks, since some might have concerns > (regarding security for instance). > > Cheers, > Darius > > On Thu, 12 Jun 2025 at 17:02, 'Emanuel Ziegler' via v8-dev < > v8-...@googlegroups.com> wrote: > >> Hi Sam, >> >> In principle, loop unrolling should already reduce the number of stack >> checks, but it could be that it's insufficient or that for whatever reason >> this optimization does not get applied here. Did you take a look at the >> generated code? >> >> Cheers, >> Emanuel >> >> On Thu, Jun 12, 2025 at 4:44 PM Sam Parker-Haynes <sam.p...@arm.com> >> wrote: >> >>> Hi! >>> >>> While running some AI code, the loop header WasmStackCheck was appearing >>> quite heavily in the profile. Disabling the checks results in ~1.5% >>> speedup. So, is it necessary to execute these for every iteration? Or could >>> we wrap inner loops, devoid of a stack check, in a new loop with one so >>> that these checks are executed for a fraction of what they are now? >>> >>> Cheers, >>> Sam >>> >>> >>> >>> -- >>> -- >>> 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. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/v8-dev/b4a77d25-21f9-4a0d-a467-8cbe48275bfbn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/b4a77d25-21f9-4a0d-a467-8cbe48275bfbn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> -- >> 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. >> > To view this discussion visit >> https://groups.google.com/d/msgid/v8-dev/CAPAU7RyGTVCKFUgJoTiDH546up4d8qJ4fQCr8aTKFBVtxUt%2BoQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/v8-dev/CAPAU7RyGTVCKFUgJoTiDH546up4d8qJ4fQCr8aTKFBVtxUt%2BoQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > Darius Mercadier > > Software Engineer > > dmerc...@google.com > > Google Germany GmbH > > Erika-Mann-Straße 33 > > 80636 München > > Geschäftsführer: Paul Manicle, Liana Sebastian > > Registergericht und -nummer: Hamburg, HRB 86891 > > Sitz der Gesellschaft: Hamburg > > Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten > haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, > löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, > dass die E-Mail an die falsche Person gesendet wurde. > > > > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > -- -- 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 visit https://groups.google.com/d/msgid/v8-dev/9c4240e3-b48f-43e1-aeb2-9953da8b9a64n%40googlegroups.com.
