search for: aliasees

On Oct 30, 2013, at 12:35 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > A long time ago (before r97733) we used to model the weakref attribute > by outputting a new declaration and a weak alias to it. This was > fairly buggy and we now implement weakref directly in clang, with the > same logic an assembler uses to implement .weakref (which is what gcc >

On 30 October 2013 15:50, Chris Lattner <clattner at apple.com> wrote: > > On Oct 30, 2013, at 12:35 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >> A long time ago (before r97733) we used to model the weakref attribute >> by outputting a new declaration and a weak alias to it. This was >> fairly buggy and we now implement weakref directly in

A long time ago (before r97733) we used to model the weakref attribute by outputting a new declaration and a weak alias to it. This was fairly buggy and we now implement weakref directly in clang, with the same logic an assembler uses to implement .weakref (which is what gcc prints). One thing that was left from that old implementation is that we still have alias to declarations and they are a

> It looks fairly likely llvm will accept arbitrary expressions as > aliasees again (see thread on llvmdev), but the restrictions inherent > from what alias are at the object level will remain, just be reworded > a bit. For example, we will have something along the lines of "the > aliasee expression cannot contain an undefined GlobalValue". And this is in...

...reject both of these uses. The first is rejected as aliases can no longer reference items other than definitions, e.g. opt: hi.ll:414:36: error: Alias must point to function or variable @SWn_srt$alias = alias private i8* bitcast (%SWn_srt_struct* @SWn_srt to i8*) The second is rejected as aliasees must[2] be global objects, which bitcasts are not, /home/ben/trees/root-llvm-head/bin/opt: utils/hpc/dist-install/build/HpcParser.ll:44714:37: error: Alias must point to function or variable @c3rB_str$alias = alias private i8* bitcast (%c3rB_str_struct* @c3rB_str to i8*)...

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

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

Hi, In order to find out-of-bound accesses to global objects with AddressSanitizer ( http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer) I need to create redzones to the left and to the right of every global variable. I tried the following: Before: @Extern = global [10 x i8] zeroinitializer, align 1 After: %0 = type { [32 x i8], [10 x i8], [54 x i8] } @Extern_asan_redzone =

Hey all, Below is the proposed format for the dump of the ThinLTO module summary in the llvm-dis utility: > ../build/bin/llvm-dis t.o && cat t.o.ll ; ModuleID = '2.o' source_filename = "2.ll" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @X = constant i32 42, section "foo", align

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

...ompatibility. Does anyone have more context on this, and why it'd be a terrible idea? For context: This seems to be designed to let LLVM implement a GNU extension in COFF libraries. However, it leads to very different behavior than we see for cl.exe (and ml.exe) on Windows; for already-defined aliasees, it injects an alternate placeholder ".weak.<alias>.default.<uniquifier>" symbol which resolves back to the current location. I admit, I'm not quite sure how this helps. If anyone can explain the purpose, I'd really appreciate it! In Windows PE/COFF files, aliases typ...

> 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

...laying 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 non-prevailing weak symbols in >> ThinLTO backends. >> >> 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 >> cas...

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.

Hi everyone, I started working on a long-standing request to have the summary dumped in a readable format to text, and specifically to emit to LLVM assembly. Proposal below, please let me know your thoughts. Thanks, Teresa *RFC: LLVM Assembly format for ThinLTO

...gt;>> 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 non-prevailing weak symbols in ThinLTO backends. >>>>>> >>>>>> 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,...

I was working on https://reviews.llvm.org/D81911 to try and fix https://bugs.llvm.org/show_bug.cgi?id=46340 . Through the review process we happened upon a design limitation or perhaps a potential mis-modelling of GlobalIFunc in the IR object hierarchy, which leads to some problems in LTO flows. To summarize, as it currently stands (and in the hopes of faithfully representing the conclusions of

Hi, I wanted to see if there was a way in IR to emit a local alias such that I would get: ``` .type _ZTVSt13bad_exception, at object # @_ZTVSt13bad_exception .globl _ZTVSt13bad_exception _ZTVSt13bad_exception: *.L_ZTVSt13bad_exception:* .long 0 # 0x0 .long (_ZTISt13bad_exception.rtti_proxy-.L_ZTVSt13bad_exception)-8 .long

On Thu, May 3, 2018 at 2:58 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi Teresa, > > I have re-read your proposal, and I'm not getting how you plan to > represent combined summaries with this. Unless I'm missing something, there > doesn't seem to be a way to write out summaries that is independent of the > global values that they relate to. Is that

Hi Teresa, I have re-read your proposal, and I'm not getting how you plan to represent combined summaries with this. Unless I'm missing something, there doesn't seem to be a way to write out summaries that is independent of the global values that they relate to. Is that something that you plan to address later? Peter On Tue, Apr 24, 2018 at 7:43 AM, Teresa Johnson <tejohnson at