[llvm-bugs] [Bug 35535] New: Wasm backend duplicate data pruning

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 5 10:18:35 PST 2017


            Bug ID: 35535
           Summary: Wasm backend duplicate data pruning
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: ncw at realvnc.com
                CC: llvm-bugs at lists.llvm.org

This is as a follow-on to COMDAT support
(https://bugs.llvm.org/show_bug.cgi?id=35533). I've split this out from bug
35533 because it's not a functional requirement; COMDAT works fine without this
refinement albeit with huge binaries.

Currently, our binary size is bigger than it need be, because duplicate data is

In a function like this:

inline const char* inlineStringFn() { return "string"; }
extern void importedFn(int* dat);
inline void inlineArrayFn() {
  const int dat[] = {1,2,3,4,5,6,7,8,9};

the string data is NOT part of a COMDAT, surprisingly. It does go in its own
section named ".rodata.<mangled inlineFn>".  However, there isn't a clear
command to the linker, as far as I can see, to ensure that the duplicate data
is pruned.  Again, in the case inlineArrayFn() it looks like the front-end is
relying on the linker to do some kind of de-deplication, because the read-only
data is put in a separate section but not put in a COMDAT, so LLD is going to
have to de-duplicate it in some other way.

In any case, string data is a special case that deserves special attention,
regardless of inline functions.

LLD needs to ensure that when linking Wasm, strings and other read-only data
sections with duplicate contents are merged.  I think ld has a pass for
de-duping constant data, and is able to special-case string data by
string-by-string de-duping, and for other data sections is able to hash the
whole section and avoid linking in duplicate data.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171205/d68b38b7/attachment.html>

More information about the llvm-bugs mailing list