similar to: [LLVMdev] How to handle aliases?

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

Hi, I am trying to compile a dynamic loader using LLVM. Part of the IR for this loader looks like this: @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global @_rtld_global = unnamed_addr global %struct.rtld_global { ... } The purpose of _rtld_local is to allow _rtld_global to be referenced without using the GOT, as this global is accessed before the dynamic loader initialises the GOT.

On Tue, Jan 17, 2017 at 7:24 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > I was wondering though what happens if we have an alias, which may or may > > not be weak itself, to a non-odr weak symbol that isn't prevailing. In > that > > case, do we eventually

On Nov 9, 2011, at 11:34 AM, Rafael Espíndola wrote: >>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >>> (even in TUs where static initialization is required to be performed), unless >>> we can prove that every translation unit will use static initialization. We >>> emit the global plus its guard variable as a single object so

>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >> (even in TUs where static initialization is required to be performed), unless >> we can prove that every translation unit will use static initialization. We >> emit the global plus its guard variable as a single object so the linker can't >> separate them (this is the ABI change).

> Unfortunately, making the comdat be for the entire function is not > conformant with the ABI, which says that you either put the variable > and its guard in different comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two comdats would still cause the same problem for us, no? So the

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

On Nov 21, 2011, at 9:05 AM, Rafael Espíndola wrote: >> Unfortunately, making the comdat be for the entire function is not >> conformant with the ABI, which says that you either put the variable >> and its guard in different comdats or you put them in a single comdat >> named for the variable. It also doesn't actually help unless we disable >> inlining. >

On Nov 7, 2011, at 9:47 AM, Richard Smith wrote: >> In cases where the C++ standard requires static initialization, >> introducing a write violates the guarantees of the C++ standard for static >> initialization. Therefore, I'm not sure the whole "make the constant >> writable" approach is actually viable. > > There is another problem which afflicts

A clarification pointed out by David Majnemer: what I"m really talking about is "comdat or comdat-semantic-equivalents" which include linkonce_odr and available_externally. As a further strategy to recover optimizations: On platforms with comdat support, we could also teach function attrs that deduction is safe for functions which are only called from within their own comdat. And

Hi Mehdi, Peter and David (and anyone else who sees this), I've been playing with some examples to handle the weak symbol cases we discussed in IRC earlier this week in the context of D28523. I was going to implement the support for turning aliases into copies in order to enable performing thinLTOResolveWeakForLinkerGUID on both aliases and aliasees, as a first step to being able to drop

Thanks, David and Peter. Some responses to Peter's email below. Teresa On Fri, Jan 13, 2017 at 3:21 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi Teresa, > > I think that to answer your question correctly it is helpful to consider > what is going on at the object file level. For your test1.c we conceptually > have a .text section containing the body of f, and

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

Hi, I believe we should get it right (and simpler) if (when…) we move to the representation we discussed last spring: https://llvm.org/bugs/show_bug.cgi?id=27866 <https://llvm.org/bugs/show_bug.cgi?id=27866> Our conclusion was that we should always have alias pointing to private anonymous and nothing else, so when we currently have: @a = global i32 0 @b = alias @a It should always

> There are also odd stuffs such as COMDAT groups or > merge-not-by-name-but-by-content sections, that may complicate the model. (I > don't think about that yet.) For comdats (on ELF) you should be able to avoid even reading the bits from subsequent files once a comdat of a given name has been found. Cheers, Rafael

> I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -------------------------------- > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE > -------------------------------- > > TU2: >

> On Jan 14, 2017, at 8:14 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Fri, Jan 13, 2017 at 9:54 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hi, > > I believe we should get it right (and simpler) if (when…) we move to the representation we discussed last spring:

> On Jan 18, 2017, at 7:11 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > >> On Sat, Jan 14, 2017 at 12:15 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jan 14, 2017, at 8:14 AM, Teresa Johnson <tejohnson at google.com> wrote: >>> >>> >>> >>> On Fri, Jan 13, 2017 at 9:54 PM, Mehdi

Hi Taewook, On Thu, Jul 28, 2016 at 4:38 PM, Taewook Oh via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Encountered “assert(GS != DefinedGlobals.end())” failure while running > ThinLTO. The assertion statement is in MustPreserveGV lambda function in > llvm::thinLTOInternalizeModule (lib/Transforms/IPO/FunctionImport.cpp). > > > > It seems that the assertion fails