[PATCH] D22613: [Profile] deprecate __llvm_profile_override_default_filename (part-1)

[Xinliang David Li via llvm-commits]

There are some other factors that make the linker to keep the extra copies.
If I remove the comdat setting, the size of clang instrumented binary's
rodata size increases from 8,684,939 to 8,709,291 (with profile path 14
chars long) -- they are all from duplicated strings.

David

On Thu, Jul 21, 2016 at 11:11 AM, Vedant Kumar <vsk at apple.com> wrote:

> That's interesting. It seems like it's enough to specify WeakAnyLinkage on
> Darwin to get the same behavior. Do you expect that to be the case? Here is
> the test I tried:
>
> $ echo "@x = weak global i32 42" > weak.ll
> $ clang weak.ll -o weak.o
>
> $ echo "extern int x;" > use_weak.c
> $ echo "int main() { return x; }" >> use_weak.c
>
> $ clang weak.o weak.o use_weak.c -o use_weak
> $ otool -s __DATA __data use_weak
> Contents of (__DATA,__data) section
> 0000000100001008        2a 00 00 00
>
> It looks like there is just one copy of the symbol in the final binary.
>
> I wonder why the comdat is needed on ELF, or whether my test is just wrong.
>
> vedant
>
> > On Jul 21, 2016, at 10:55 AM, Xinliang David Li <davidxl at google.com>
> wrote:
> >
> >
> >
> > On Thu, Jul 21, 2016 at 10:52 AM, Vedant Kumar <vsk at apple.com> wrote:
> > vsk added a comment.
> >
> > Nice, just one concern.
> >
> >
> > ================
> > Comment at: lib/Transforms/Instrumentation/InstrProfiling.cpp:615
> > @@ +614,3 @@
> > +      ProfileNameVar->setComdat(M->getOrInsertComdat(
> > +          StringRef(INSTR_PROF_QUOTE(INSTR_PROF_PROFILE_NAME_VAR))));
> > +  }
> > ----------------
> > What's the advantage of placing the file name var in a comdat if it
> already has weak linkage? Would some ELF tests break without this?
> >
> >
> > It won't break, but the final binary will contain more than one copies
> of the symbols which wastes space. With Comdat, there is only one copy in
> the final link. Note current behavior (with private linkage will also
> result in multiple copies which is fixed here).
> >
> > David
> >
> >
> >
> > https://reviews.llvm.org/D22613
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160721/4d7fbe8f/attachment.html>