Rafael Espíndola
2013-Oct-30 19:35 UTC
[LLVMdev] [RFC] Alias should not point to declarations
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 very different concept from alias to definitions. Alias to definitions are just another symbol pointing to the same position in the object file. For example, given @bar = alias void ()* @foo define void @foo() { ret void } Both ELF end COFF just get two symbols (foo and bar or _foo and _bar) pointing to the same section and offset. Alias to declarations are a lot fuzzier. They are still considered definitions according to GlobalValue::isDeclaration(), but the IR @bar = alias void ()* @foo declare void @foo() produces an empty ELF file and COFF files with two undefined symbols, but no connection between them. There is no good answer, since neither COFF nor ELF have an alias directive to pass the connection down to the linker. The only possible use right now seems to be what we used to do for weakref. Given @bar = hidden alias void ()* @foo declare void @foo() define void @zed() { call void @foo() call void @bar() ret void } llc with the pic relocation model will produce a R_X86_64_PLT32 and a R_X86_64_PC32, both pointing to foo. That is, the alias acts as an alternative declaration. The supported way of doing this is to have a proper declaration in the file using the symbol: declare hidden void @bar() declare void @foo() define void @zed() { call void @foo() call void @bar() ret void } and an alias on the file defining foo: @bar = hidden alias void ()* @foo define void @foo() { ret void } With all that in mind, the attached patch changes the verifier to reject aliases to declarations and updates that language reference. The patch also updates the testcases. They seem to be almost all from the old weakref implementation. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: t.patch Type: text/x-patch Size: 20378 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131030/28668dbd/attachment.bin>
Chris Lattner
2013-Oct-30 19:50 UTC
[LLVMdev] [RFC] Alias should not point to declarations
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 > 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 be an actual GlobalValue, disallowing constexprs completely. -Chris
Tim Northover
2013-Oct-30 20:16 UTC
[LLVMdev] [RFC] Alias should not point to declarations
Hi Rafael,> With all that in mind, the attached patch changes the verifier to > reject aliases to declarations and updates that language reference.MachO has an R_INDR (== "indirect") symbol flag/type that (from my understanding) exactly reflects this. The linker is supposed to record the alias and define both symbols when the referee is defined. In fact, I've been working on exposing this to C code very recently so I'd obviously quite like it to stick around. Currently I've not submitted a patch because, even though it's documented, ld64 doesn't have support just yet so I can't actually test things properly. I think the only benefit is going to be to compile-time and source-structure, but it would still be a shame to lose it when LLVM is so close to having the ideal model right now. Cheers. Tim.
Rafael Espíndola
2013-Oct-30 20:29 UTC
[LLVMdev] [RFC] Alias should not point to declarations
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 clang, with the >> same logic 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 be an actual GlobalValue, disallowing constexprs completely.This is llvm.org/pr10367, right? Cheers, Rafael
Rafael Espíndola
2013-Oct-30 20:59 UTC
[LLVMdev] [RFC] Alias should not point to declarations
On 30 October 2013 16:16, Tim Northover <t.p.northover at gmail.com> wrote:> Hi Rafael, > >> With all that in mind, the attached patch changes the verifier to >> reject aliases to declarations and updates that language reference. > > MachO has an R_INDR (== "indirect") symbol flag/type that (from my > understanding) exactly reflects this. The linker is supposed to record > the alias and define both symbols when the referee is defined. In > fact, I've been working on exposing this to C code very recently so > I'd obviously quite like it to stick around. > > Currently I've not submitted a patch because, even though it's > documented, ld64 doesn't have support just yet so I can't actually > test things properly. > > I think the only benefit is going to be to compile-time and > source-structure, but it would still be a shame to lose it when LLVM > is so close to having the ideal model right now.We chatted a bit or IRC and it does look like N_INDR has the behaviour of llvm aliases. An alias to a declaration is a definition for example. It is documented here: https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html I will try to make the ELF/COFF restrictions explicit with errors in codegen instead. Cheers, Rafael