similar to: [LLVMdev] weak_odr constant versus weak_odr global

Hi [Adding cfe-dev to widen the net] On Tue, November 1, 2011 23:19, Richard Smith wrote: > We recently narrowed down a clang regression to the following testcase: > > struct S { static const int x; }; > template<typename T> struct U { static const int k; }; > template<typename T> const int U<T>::k = T::x; > > #ifdef TU1 > extern int f(); > const int

On Tue, Nov 1, 2011 at 5:19 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Hi > > [Adding cfe-dev to widen the net] > > On Tue, November 1, 2011 23:19, Richard Smith wrote: >> We recently narrowed down a clang regression to the following testcase: >> >> struct S { static const int x; }; >> template<typename T> struct U { static const int k;

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

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

I tried a small variation: struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; #ifdef TU1 extern int f(); const int S::x = 42; int main() { return f() + reinterpret_cast<long>(&U<S>::k); } #endif #ifdef TU2 int f() { return U<S>::k; } #endif and it crashes with gcc too

2011/11/7 Rafael Espíndola <rafael.espindola at gmail.com>: > I tried a small variation: > > struct S { >  static const int x; > }; > template<typename T> struct U { >  static const int k; > }; > template<typename T> const int U<T>::k = T::x; > > #ifdef TU1 > extern int f(); > const int S::x = 42; > int main() { >  return f() +

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

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 Mon, November 7, 2011 16:31, Eli Friedman wrote: > 2011/11/7 Rafael Espíndola <rafael.espindola at gmail.com>: >> I tried a small variation: >> >> >> struct S {  static const int x; >> }; >> template<typename T> struct U {  static const int k; >> }; >> template<typename T> const int U<T>::k = T::x; >> >>

Hi! LLVM newbie here, I was mainly working on the frontend so far. We had a small hackathon project idea to piggyback on LTO to detect dead code (unused functions). The basic idea is to compile the code for every target and dump the removed functions. Intersect the function symbol names for each target and those functions should be safe to remove from the source code (unless there were some

Thanks! On Mon, Jan 27, 2020 at 6:05 PM Teresa Johnson <tejohnson at google.com> wrote: > By default even regular LTO now has module summaries (like the kind used > for ThinLTO). LTO will then run index based dead symbol analysis here: > http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#923. Then when linkRegularLTO is > called here: http://llvm-cs.pcc.me.uk/lib/LTO/LTO.cpp#935, it

There should be no semantic difference between linkonce_odr and weak_odr, except that weak_odr is non-discardable. Why doesn't the autohide optimization work just as well on weak_odr + unnamed_addr as linkonce_odr + unnamed_addr? On Tue, Feb 6, 2018 at 5:35 PM, Steven Wu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I recently found that thinLTO doesn't deal

That is a good question and I don't know. The optimization is defined include/llvm/Analysis/ObjectUtils.h. If I enable that for weak_odr + unnamed_addr, no tests are failing so I guess it is a safe optimization? :) It is probably because the autohide optimization is targeted at c++ templates and inline functions and we know they have linkonce_odr linkage, which suggests whoever uses this

>From looking at the code, it seems like LLVM is basically opting MachO into -fvisibility-inlines-hidden all the time, i.e. if the function is linkonce, it's discardable, so mark it hidden to pretend the compiler inlined it and discarded it. However, this isn't conforming, because the addresses of inline functions will no longer compare equal across DSOs. Realistically, nobody cares

Hello Teresa, Thank you for your reply. I’m trying to create a small repro but find it hard to nail down because originally it is a big build. This happens with gold linker. Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Thursday, July 28, 2016 at 5:08 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev]

Hello Teresa, Thank you for your analysis. One thing to note is that the global materializer materializes the value as a function declaration, not a function definition. As I pasted on my first email, ; Materializable ; Function Attrs: nounwind uwtable define weak_odr void @foo(%1*) unnamed_addr #7 comdat($comdat1) align 2 personality i32 (...)* @__gxx_personality_v0 {} is materialized to ;

Hi Richard, >>> and it crashes with gcc too :-( The original testcase works because gcc >>> folds the value into main even at -O0. > > Indeed, I filed gcc bug#50968 for this last week. are you sure this is the right gcc bug number? Ciao, Duncan.

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to