> 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: r210062. Let us know how it looks from GHC's point of view. Cheers, Rafael
On Tue, Jun 3, 2014 at 1:29 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:> > 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: r210062. > > Let us know how it looks from GHC's point of view.I think we might be able to relax our restrictions against aliases referring to declarations if the alias is private. If the alias is private, then the label never appears in the object file. The alias is merely a Constant with an internal name. What do you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140603/d0db363c/attachment.html>
> I think we might be able to relax our restrictions against aliases referring > to declarations if the alias is private. If the alias is private, then the > label never appears in the object file. The alias is merely a Constant with > an internal name. What do you think?It feels a bit too fuzzy. Some reasons: * Private does show up on the symbol table if we end up needing a relocation to it. * In general, what would it mean to use an alias to undefined on ELF and COFF? It would be bad to be in a situation where the program works if the use is optimized out but codegen asserts if it is not. * It is not clear what it would buy you. With what we have on trunk there is almost not consistency check until we get to the verifier, so you can even eagerly create alias and delete aliases you don't need before running the verifier. Cheers, Rafael
Reid Kleckner <rnk at google.com> writes:> On Tue, Jun 3, 2014 at 1:29 PM, Rafael Espíndola <rafael.espindola at gmail.com >> wrote: > >> > 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: r210062. >> >> Let us know how it looks from GHC's point of view. > > > I think we might be able to relax our restrictions against aliases > referring to declarations if the alias is private. If the alias is > private, then the label never appears in the object file. The alias is > merely a Constant with an internal name. What do you think?Any word on this? As far as I can tell we are stuck on the GHC side until we can alias declarations due to the existence of untyped external references in the C-- representation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140720/9e39156e/attachment.sig>