similar to: Weak symbol/alias semantics

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

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

> 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

> 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 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 Wed, Jan 18, 2017 at 7:16 AM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > >> The rule should be that the alias to aliasee link is never broken. The > >> reason being that an alias at the file level is just another symbol with > >> the same value. > >> > >> So if foo is an alias to bar, accessing that foo will always be

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 <

On Mon, May 1, 2017 at 11:06 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-04-25 12:11 GMT-07:00 Peter Collingbourne <peter at pcc.me.uk>: > >> Hi all, >> >> I've been making a number of changes to the summary representation >> recently, and I wanted to lay out some of my plans so that folks are aware >> of my ultimate

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

On Fri, Dec 23, 2016 at 11:04 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> Hey, >> >> As I’m playing with Metadata lazy-loading, I added a verifier right

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

> On Dec 23, 2016, at 9:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Thu, Dec 22, 2016 at 8:55 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hey, > > As I’m playing with Metadata lazy-loading, I added a verifier right before running the IRLinker in FunctionImport.cpp, and it does not pass (on

Hi all, I've been making a number of changes to the summary representation recently, and I wanted to lay out some of my plans so that folks are aware of my ultimate direction with this. Basically I want to move the summary into the irsymtab that we will be storing to disk after D32061 lands. This would help solve a number of problems: - To read a summary, you need to read all summaries in a

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]

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 because it fails to recover the "original name" of the global value. ModuleSummaryIndex::getOriginalNameBeforePromote attempts to get the

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 ;

I am tracking a problem with ThinLTO on Linux using gold and elf files where there is a disconnect between gold’s treatment of comdat groups and ThinLTO’s decisions about which weak references to convert to available externally. The net result is a definition is lost and a relocation entry is not handled. My status is summarized: https://bugs.llvm.org/show_bug.cgi?id=32980 Anyone familiar with

It was r274523. I’m not sure it was the same module. By mistake I restarted the build with the previous version without backing backing up the build artifacts :( Thanks, Taewook From: Teresa Johnson <tejohnson at google.com> Date: Friday, July 29, 2016 at 3:30 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [ThinLTO]

As a follow up to https://reviews.llvm.org/D20217 I would like to use lto/thinlto to refine when a symbol is marked as local/preemptable. I'm not very familiar with lto though so would appreciate some guidance about how best to go about this. Regards Sean Fertile