Thanks, Clemens! I'm pleased to hear that the preserve_most semantics can still be changed, because I think option 3 is the most appealing. I'll look into implementing it in LLVM; if all goes well, we won't need to change anything in V8.
Best, Seth On Tuesday, November 21, 2023 at 6:02:54 AM UTC-8 Clemens Backes wrote: > Thanks for raising this issue. Looks like no one checked the assembly > that's being generated on Windows. > > I agree that we should do something about this. As both the preserve_most > and preserve_all calling conventions are still experimental anyway, I think > they can still both be changed in LLVM. Note that also the > preserve_most attribute had issues originally, which Anton (CCed) fixed in > https://reviews.llvm.org/D141020. > > My personal preference for a fix would be either (3) or (5), but both > would need fixes on the LLVM side. If that doesn't work we can also do (2) > in the meantime. > > > > On Mon, Nov 20, 2023 at 5:33 PM '[email protected]' via v8-dev < > [email protected]> wrote: > >> Hi everyone, >> >> I noticed some unfortunate disassembly recently and am curious about >> whether y'all are aware of this problem or have any ideas about how to fix >> it. >> >> Problem description: >> >> The Clang preserve_most attribute defines a new calling convention where >> all floating-point registers are caller-saved. This is a mismatch with the >> normal Windows calling convention, and causes any caller of a >> V8_PRESERVE_MOST function to save and restore xmm6 through xmm15, at a cost >> of 126 bytes of extra instructions per calling function. When there are >> many callers to a V8_PRESERVE_MOST function, this size cost adds up: for >> example, there are many hundreds of instantiations of the template >> AllocationDispatcher::Invoke in Chromium, and each one calls a >> V8_PRESERVE_MOST function. I tried disabling V8_PRESERVE_MOST and found >> that it reduced the size of a release build of chrome.dll by a whopping 2 >> MB. >> >> The preserve_most calling convention is working correctly, as defined at >> https://clang.llvm.org/docs/AttributeReference.html#preserve-most . >> However, it's a bad fit for Windows. This problem has been raised in the >> LLVM discussion forum: >> https://discourse.llvm.org/t/conv-c-and-conv-preservemost-mix-badly-on-windows-x64/73054 >> >> . >> >> The discussion question: what should we do about this? I could imagine a >> few answers: >> >> 1. Do nothing; it's working fine and we're okay with the code-size cost >> 2. Disable preserve_most for Windows builds, since the cost of saving and >> restoring all of those floating-point registers outweighs the benefit of >> avoiding similar stack access for general-purpose registers >> 3. Redefine preserve_most in a platform-specific way so it treats xmm6 >> through xmm15 as callee-save on Windows >> 4. Define a new Clang attribute preserve_most_win which is like >> preserve_most but with Windows semantics for floating-point registers >> 5. Use preserve_all instead on Windows, to declare that all >> floating-point registers are callee-save. This is appealing because it >> pushes the cost of saving and restoring into the cold function, but when I >> tried it, I got a bunch of internal compiler errors. >> >> Best, >> Seth >> >> -- >> -- >> v8-dev mailing list >> [email protected] >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/3e5b967d-553e-40dd-ad7b-4a606d750f85n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/v8-dev/3e5b967d-553e-40dd-ad7b-4a606d750f85n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Clemens Backes > > Software Engineer > > [email protected] > > 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 [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/fefe414a-781b-406b-b041-45ac5c0a9c60n%40googlegroups.com.
