search for: comdats

...inly be taught to. >> This guarantees correctness as long as every translation unit emits the >> code the same way, which is exactly what we'd get from an ABI change, >> except without actually breaking ABI conformance. > > I like this. We already have basic support for COMDATs, but yes, it > needs to be extended. So far we just create trivial COMDATs in codegen > for weak objects. > > We also need the IL linker itself needs to work on COMDATs too > otherwise this bug would still exist when doing LTO. > > In the "extended" example we would...

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 solution in the end is to emit: TU1: -------------------------------- @_ZN1UI1SE1kE =...

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. > > I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -----------...

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

...et, but it could certainly be taught to. > This guarantees correctness as long as every translation unit emits the > code the same way, which is exactly what we'd get from an ABI change, > except without actually breaking ABI conformance. I like this. We already have basic support for COMDATs, but yes, it needs to be extended. So far we just create trivial COMDATs in codegen for weak objects. We also need the IL linker itself needs to work on COMDATs too otherwise this bug would still exist when doing LTO. In the "extended" example we would output @_ZN1UI1SE1kE = weak_odr c...

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

...this seem reasonable to folks? Thanks, -- -- Peter [0] This means that no GlobalValue or comdat name can contain a null, but this isn't substantially more restrictive than what we already have. The restriction already exists in the form of an assert for value names containing nulls (but not comdats) and we reject value and comdat names containing nulls in the textual IR parser. The COFF/ELF/MachO object formats do not support nulls in symbol or comdat names. The wasm format could in principle support nulls in symbol names, but as mentioned we already reject nulls early for IR symbols and wasm...

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:

...ng 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 would have to be something like * If an alias is declared to a isWeakForLinker symbol in one object file, it must be defined in all. This is very restrictive rule. For example, given struct A { virtual ~A() {} }; struct B : public A { virtual ~B() {} }; It...

...le_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 then we could do some work in Clang (or other FEs) to try to form larger comdats when safe to do so. For example with C++, inline method definitions inside of class bodies could have a merged comdat I think because the class body can't change between translation units. This would in turn allow, for example, continuing to get full deduction for private inline methods inside...

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