This is an archive of the discontinued LLVM Phabricator instance.

[lld][WebAssembly] Take advantage of extended const expression when available
ClosedPublic

Authored by sbc100 on Mar 10 2022, 3:18 PM.

Details

Summary

In particular, when extended-const is available and we building PIC
code we no longer need to combine output segments into a single segment
that can be initialized at __memory_base. Instead each segment
can encode its offset from __memory_base in its initializer. e.g.

(i32.add (global.get __memory_base) (i32.const offset)

Diff Detail

Event Timeline

sbc100 created this revision.Mar 10 2022, 3:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 10 2022, 3:18 PM
sbc100 requested review of this revision.Mar 10 2022, 3:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 10 2022, 3:18 PM
sbc100 updated this revision to Diff 414686.Mar 11 2022, 9:52 AM
  • cleanup

Would there still be an advantage to combining the segments? e.g. would the library load faster if there were only one?

Would there still be an advantage to combining the segments? e.g. would the library load faster if there were only one?

We already combine segments of the same type/prefix unless --no-merge-data-segments is passed... so in the normal case there are just a fixed number or possible output segments: .data .bss .tdata .tbss, plus any user-defined segments. This later-phase combining was always just a stop gap to handler the lack of extended const expressions. See the description of https://reviews.llvm.org/D96453 for why we delay the merging in this case.

Would there still be an advantage to combining the segments? e.g. would the library load faster if there were only one?

We already combine segments of the same type/prefix unless --no-merge-data-segments is passed... so in the normal case there are just a fixed number or possible output segments: .data .bss .tdata .tbss, plus any user-defined segments. This later-phase combining was always just a stop gap to handler the lack of extended const expressions. See the description of https://reviews.llvm.org/D96453 for why we delay the merging in this case.

Even if we decided that this second level combining was a good idea more generally that isn't really related to this PR and could be an option for all build (unrelated to PIC or sharedMemory, or extendedConst). But i think keeping the high level sections separate by default probably makes sense, given how few there are in most programs. Also, binaryen can always combine them if folks want to micro-optimize.

sbc100 updated this revision to Diff 415108.Mar 14 2022, 9:03 AM
  • rebase

Ah, right I forgot we already combined the default segments. That's probably fine as a default behavior.

lld/test/wasm/pie.ll
96
150

I don't see a RUN line for DISASSEM-EXTENDED-CONST?

lld/test/wasm/tls-non-shared-memory.s
144
lld/wasm/SyntheticSections.h
277

Does this comment need updating?

lld/wasm/Writer.cpp
930–932
sbc100 updated this revision to Diff 415266.Mar 14 2022, 4:19 PM
sbc100 marked 3 inline comments as done.
  • feedback
sbc100 added inline comments.Mar 15 2022, 11:43 AM
lld/wasm/SyntheticSections.h
277

I think the comment is still accurate. What has changed is that these globals might not need relocation.. but this comment doesn't touch on the relocation part.

dschuff accepted this revision.Mar 15 2022, 5:28 PM
dschuff added inline comments.
lld/test/wasm/pie.ll
119

maybe write what instructions these encoding correspond to?

lld/wasm/Writer.cpp
930–932
1567
1569
This revision is now accepted and ready to land.Mar 15 2022, 5:28 PM
sbc100 updated this revision to Diff 415653.Mar 15 2022, 5:47 PM
sbc100 marked 3 inline comments as done.
  • feedback
This revision was landed with ongoing or failed builds.Mar 15 2022, 5:50 PM
This revision was automatically updated to reflect the committed changes.