search for: comdate

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

I've been digging into COMDAT with regular LTO, specifically in the context of the LLVM gold plugin. The GCC WHOPR documentation specifies that the linker will resolve all COMDAT groups to the IR-provided definitions, if available. Additionally it specifies that "When the WPA phase produces the definition of the COMDAT symbol in a new object file, that definition should not be in a COMDAT

> 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

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. >

Given the following C++ code: ``` // test.cpp struct Foo { int public_foo(); int outside_foo(); [[gnu::always_inline]] int inline_foo() { int x = outside_foo(); if (x % 17) { x += 1; } return x; } [[gnu::noinline]] int inline_bar1() { int x = inline_foo(); if (x % 23) { x += 2; } return x; } [[gnu::noinline]] int inline_bar2() {

> 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: >

>> 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).

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

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 Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > >> So I was looking into handling ELF groups today in the Atom model. It >> appears that we will need to add the concept of a group to the atom >> model directly, as modeling it with references fails to capture some >>

On Dec 19, 2012, at 4:53 PM, Michael Spencer wrote: > On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >> On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: >>> So I was looking into handling ELF groups today in the Atom model. It >>> appears that we will need to add the concept of a group to the atom >>> model

I support Nick's option too. I think handling groups is another example of using follow on references. One question is how does an atom outside the group refer to the main atom here ? Will not garbage collection cleanup the main atom/signature atom because there are no references ? Thanks - Shankar Easwaran On Wed, Dec 19, 2012 at 5:00 PM, Nick Kledzik <kledzik at apple.com> wrote:

My recent change to use more aliases for destrucors in clang has opened a can of worms. The fundamental issue is that aliasing in object files have fairly complex semantics. For example, on ELF if a symbol is defined in a COMDAT in one object file, it must be defined in every object file that has that COMDAT. Given that weak symbols get implemented with COMDATs, the actual rule at the llvm level

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

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

> 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

So I was looking into handling ELF groups today in the Atom model. It appears that we will need to add the concept of a group to the atom model directly, as modeling it with references fails to capture some semantics. http://www.sco.com/developers/gabi/latest/ch4.sheader.html Groups in ELF are collections of sections that must be either included or excluded as a unit. They also are used to

Hi Nick, Bigcheese, I wanted to add support to support .gnu.linkonce sections in the resolver. _*About .gnu.linkonce sections*_ .gnu.linkonce sections were primarily present in ELF that was used in a way to model COMDAT in early ELF implementations. We have seen usecases of .gnu.linkonce sections used in various object files(mainly libc), and I think its much needed to support this style in

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

On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote: > So I was looking into handling ELF groups today in the Atom model. It > appears that we will need to add the concept of a group to the atom > model directly, as modeling it with references fails to capture some > semantics. > > http://www.sco.com/developers/gabi/latest/ch4.sheader.html > > Groups in ELF are