search for: aliasee

...ogic an assembler uses to implement .weakref (which is what gcc > prints). This makes sense to me, but I'm not an expert on ELF aliases. If you're working in this area, there is something that has been bugging me for years about GlobalAlias: because we require the type of the alias and aliasee to match, we have to allow constant exprs in the aliasee (see GlobalAlias::getAliasedGlobal). This representation is bad for several reasons. I think it would be much better to change GlobalAlias to allow the aliasee to have a different type than the alias itself, and then require the aliasee to...

...to implement .weakref (which is what gcc >> prints). > > This makes sense to me, but I'm not an expert on ELF aliases. > > If you're working in this area, there is something that has been bugging me for years about GlobalAlias: because we require the type of the alias and aliasee to match, we have to allow constant exprs in the aliasee (see GlobalAlias::getAliasedGlobal). > > This representation is bad for several reasons. I think it would be much better to change GlobalAlias to allow the aliasee to have a different type than the alias itself, and then require the al...

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

...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 the same > >> as accessing that bar, regardless of eith...

...weak1.c, which is in > the > > comdat that gets dropped by the linker. So is it not legal to have an > alias > > to a weak symbol in a comdat (i.e. alias from outside the comdat)? We > don't > > complain in the compiler. > > 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 the same > as accessing that bar, regardless of either of them being weak. I say > *that* foo...

...f this struct. The compilation passes, but the resulting object looks like this: 000000000060d150 B Extern 000000000060d150 B Extern_asan_redzone I.e. @Extern points to the beginning of @Extern_asan_redzone instead of middle. Also, the comment in GlobalAlias.h says: /// getAliasedGlobal() - Aliasee can be either global or bitcast of /// global. This method retrives the global for both aliasee flavours. So, the question: can I get an alias pointing to the middle of a GlobalVariable? How? If not, is there some other way to create a left redzone for a global variable? Thanks, --kcc ------...

...@boop() ret void } declare void @boop() ; Module summary: ; testtest (External linkage) ; Function (2 instructions) ; Calls: boop ; X (External linkage) ; Global Variable ; afun (External linkage) ; Function (2 instructions) ; Refs: ; a ; a (Weak any linkage) ; Alias (aliasee X) I've implemented the above format in the llvm-dis utility, since there currently isn't really a way of getting ThinLTO summaries in a human-readable format. Let me know what you think of this format, and what information you think should be added/removed. Thanks, Charles -------------...

...module)? I looked at the > logic in renameModuleForThinLTO and all the conversions to > available_externally are predicated on it being in the provided > GlobalsToImport set. But in FunctionImport.cpp selectCallee() we > specifically prevent importing of aliases that would result in the aliasee > becoming available_externally. Presumably the resulting IRLinked dest > module looks legit, otherwise we would have later verifier failures. > > > So the source module is: > > @weakalias = weak alias void (...), bitcast (void ()* @globalfunc1 to void > (...)*) > define...

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

...inking (in the dest module)? I looked at the logic in renameModuleForThinLTO and all the conversions to available_externally are predicated on it being in the provided GlobalsToImport set. But in FunctionImport.cpp selectCallee() we specifically prevent importing of aliases that would result in the aliasee becoming available_externally. Presumably the resulting IRLinked dest module looks legit, otherwise we would have later verifier failures. So the source module is: @weakalias = weak alias void (...), bitcast (void ()* @globalfunc1 to void (...)*) define void @globalfunc1() #0 { entry: ret void...

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

...pretty sure mayBeOverridden is not intended to care about LD_PRELOAD) and results in a lot of deoptimisation. I'm thinking of introducing a new function GlobalAlias::mayBeResolved() which returns true if mayBeOverridden() returns false and the visibility of the alias is the same as that of the aliasee, and converting over the relevant clients of mayBeOverridden to use this new function. Thanks, -- Peter

..., insts: 3, funcFlags: {readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0}, calls: {{callee: ^2, hotness: unknown}}, refs: {^1}}}}^5 = gv: {guid: 18040127437030252312, name: barAlias, summaries: {alias: {module: ^0, flags: {linkage: extern, notEligibleToImport: 0, live: 0, dsoLocal: 1}, aliasee: ^4}}}Like metadata, the fields are tagged (currently using lower camel case, maybe upper camel case would be preferable).The proposed format has a structure that reflects the data structures in the summary index. For example, consider the entry “^4”. This corresponds to the function “bar”. The ent...

...day other than because we map the object-level limitations in the IR, but I can miss something (we don’t have alias on Darwin either…). > > Allowing available_externally alias helps simplify the case where we have a non-prevailing weak alias. We would still need to address the case where the aliasee is non-prevailing, which I think is the trickier situation to handle. I'm missing something, aren't we talking about the proposal where all aliasee are always private? Mehdi >> >> >>> >>> I need to think through the various permutations of linkage types a...

...itation 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 that discussion): * Calling getBaseObject() on a GlobalAlias whose aliasee is a GlobalIFunc currently returns null. * Calling getBaseObject() on a GlobalIFunc returns its resolver function. * This causes computeAliasSummary in ModuleSummaryAnalysis to crash on a null dereference for an alias-to-ifunc situation. * A GlobalIFunc and its resolver are *not* interchangeable: a...

...ocal. I can guarantee that `symbol_A` will be, but `symbol_B` needs to be a global with default visibility. My solution around this is to emit a local alias, but the issue is that with optimizations (-O3), the latter snippet seems to "resolve" the aliases and instead replaces them with my aliasee (_ZTVSt13bad_exception) which is not dso_local. An alternative solution to my problem would also be finding a way to somehow prevent the aliases from being "optimized out". Any ideas on either (1) IR that can codegen into my first snippet or (2) prevent my alias in the second snippet fro...

...readOnly: 0, noRecurse: 0, >> returnDoesNotAlias: 0}, calls: {{callee: ^2, hotness: unknown}}, refs: >> {^1}}}}^5 = gv: {guid: 18040127437030252312, name: barAlias, summaries: >> {alias: {module: ^0, flags: {linkage: extern, notEligibleToImport: 0, live: >> 0, dsoLocal: 1}, aliasee: ^4}}}Like metadata, the fields are tagged >> (currently using lower camel case, maybe upper camel case would be >> preferable).The proposed format has a structure that reflects the data >> structures in the summary index. For example, consider the entry “^4”. This >> corres...

...s: {readNone: 0, readOnly: 0, noRecurse: 0, > returnDoesNotAlias: 0}, calls: {{callee: ^2, hotness: unknown}}, refs: > {^1}}}}^5 = gv: {guid: 18040127437030252312, name: barAlias, summaries: > {alias: {module: ^0, flags: {linkage: extern, notEligibleToImport: 0, live: > 0, dsoLocal: 1}, aliasee: ^4}}}Like metadata, the fields are tagged > (currently using lower camel case, maybe upper camel case would be > preferable).The proposed format has a structure that reflects the data > structures in the summary index. For example, consider the entry “^4”. This > corresponds to the fun...