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.

Reply via email to