[llvm-bugs] [Bug 50563] New: Implement cstring literal merging

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50563

            Bug ID: 50563
           Summary: Implement cstring literal merging
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: jezreel at gmail.com
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

Created attachment 24903
  --> https://bugs.llvm.org/attachment.cgi?id=24903&action=edit
ld64 cstring misalignment crash

Mergeable cstring literals are found under the `__TEXT,__cstring` section. In
contrast to ELF, which puts strings that need different alignments into
different sections, clang's Mach-O backend puts them all in one section.
Strings that need to be aligned have the `.p2align` directive emitted before
them, which simply translates into zero padding in the object file.

I *think* ld64 extracts the desired per-string alignment from this data by
preserving each string's offset from the last section-aligned address. I'm not
entirely certain since it doesn't seem consistent about doing this; but perhaps
this can be chalked up to cases where ld64 has to deduplicate strings with
different offset/alignment combos -- it seems to pick one of their alignments
to preserve. This doesn't seem correct in general; see the attachment, which
can induce ld64 to produce a crashing binary just by linking in an additional
object file that only contains cstrings and no code.

Moreover, this scheme seems rather inefficient: since unaligned and aligned
strings are all put in the same section, which has a single alignment value, it
doesn't seem possible to tell whether a given string doesn't have any alignment
requirements. Preserving offset+alignments for strings that don't need it is
wasteful.

In practice, the crashes seen so far seem to stem from x86_64 SIMD operations
on cstrings. X86_64 requires SIMD accesses to be 16-byte-aligned. So for now,
I'm thinking of just aligning all strings to 16 bytes on x86_64. This is indeed
wasteful, but implementation-wise it's simpler than preserving per-string
alignment+offsets. It also avoids the aforementioned crash after deduplication
of differently-aligned strings. Finally, the overhead is not huge: using
16-byte alignment (vs no alignment) is only a 0.5% size overhead when linking
chromium_framework.

This is a pretty unprincipled heuristic, but we can always revisit it later.
For now, I'd like to see how many CFStrings ICF can remove after we dedup the
cstrings.

(Another heuristic I considered: clang seems to only emit SIMD operations for
strings > 16 bytes, so I tried only aligning these longer strings, but it was a
difference of 0.1% -- didn't seem worth the additional implementation
complexity.)

-- 
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/20210602/06f1e4fc/attachment-0001.html>