We did a little exploration on this when trying to optimize shuffles, see relevant design doc ( https://docs.google.com/document/d/1uCYwyQYjgNAtaXDNgHusDGCV1m9YGhOWJx2eqzv2rdI/edit). We ultimately decided against it because we found another way to improve shuffle performance without adding a constant pool.
+Brown, Andrew <andrew.br...@intel.com> fyi, since you have interest in exploring a 128-bit constant pool as well. On Wed, Mar 17, 2021 at 5:19 AM Clemens Backes <cleme...@chromium.org> wrote: > Hi Dan, > > that sounds like an interesting idea. In fact, I considered implementing a > Wasm constant pool for floating point constants, but SIMD code might > benefit even more. > Note that in Wasm code we do not have a root register (currently), so any > access to the isolate root is a few indirections away. I am also not sure > I fully understand how you plan to use external references to reference > to dynamically generated constants. > > An alternative to allocating on the heap might be allocating in (or close > to) the Wasm code space, and use PC-relative addressing. For security > reasons, we should try to make the constant pool non-executable, so if we > decide to allocate *in* the Wasm code space (instead of close by) we > should reserve a whole page and remove execute permissions from that page. > > I think a good next step would be starting a little design doc (see > https://v8.dev/docs/design-review-guidelines). I would propose to > initially include @Zhi An Ng <z...@chromium.org> and me, and we can add > more people once we figure out a working solution. > > Thanks for working on this! > > -Clemens > > On Tue, Mar 16, 2021 at 11:07 PM Dan Weber <dwe...@gmail.com> wrote: > >> Hi everyone, >> >> I wanted to approach the group to understand the feasibility of creating >> a root relative constant pool for WASM to support reuse of intermediate >> constants generated during complex instruction sequences. >> >> Right now, when a complex instruction sequence like shuffle or swizzle >> operates and cannot find an architectural match for the requested >> operation, it generates in flight code to build shuffle masks which are >> passed to pshufb on x64 and tbl on a64. Due to the current nature of the >> code generator / assembler, these can be regenerated multiple times even if >> the input is constant ( >> https://bugs.chromium.org/p/v8/issues/detail?id=11545). >> >> Two options exist for resolving this. >> >> 1) Generating a constant pool for the code to use at compile time and >> loading the data from there. >> 2) Lifting sections of multi instruction code up to the graph for >> optimization and reduction. >> >> Each is a partial solution since both can benefit from the other. >> >> What I'd like to enquire now is the first option -- the feasibility of >> implementing an isolate root relative constant pool. >> >> From what I can see, this might be an easy and effective solution covering >> address moves, security concerns, and alignment. >> >> Since isolate() has a single coherent heap that is garbage collected and >> moved (https://v8.dev/blog/embedded-builtins), one can allocate objects >> relative to the root. If you use it with the ExternalReference operand >> mechanism we've been using, it'll automatically generate all of the address >> constants relative to the root register ( >> https://source.chromium.org/chromium/chromium/src/+/master:v8/src/codegen/x64/macro-assembler-x64.cc;l=124;bpv=1;bpt=1). >> This should preclude any concerns about addresses moving when the heap >> moves or gets reallocated. Likewise, isolate()->factory() provides >> mechanisms for aligning the pointers on each allocation. As such, if an >> external data structure such as a map or hash map is used to track the >> constants at code generation time, then each constant can be allocated >> individually on the isolate heap without respect to any other. If the heap >> persists the entire duration of the executed code and is deallocated at the >> end, then there are no memory management concerns. Lastly, there should be >> no security concerns since the data allocated on the isolate heap will not >> be executable by default. >> >> Is this correct? If so, what's the appropriate process for submitting and >> reviewing a design proposal? >> >> Dan >> >> -- >> -- >> 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/CAAg-m6qF47m8fP81GoeeM4YJBaBAC8%2BY_z%3DcmanviBBeQTsD_A%40mail.gmail.com >> <https://groups.google.com/d/msgid/v8-dev/CAAg-m6qF47m8fP81GoeeM4YJBaBAC8%2BY_z%3DcmanviBBeQTsD_A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > > Clemens Backes > > Software Engineer > > cleme...@google.com > > Google Germany GmbH > > Erika-Mann-Straße 33 > > 80636 München > > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado > > 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 on the web visit https://groups.google.com/d/msgid/v8-dev/CAP2LTJ1mRUt%2BR%2BM%3DX3rKFvrGVpTMG9uzdgnoCq99Qj2scyTL_A%40mail.gmail.com.