[PATCH] D22642: CodeGen: Clean up implementation of vtable initializer builder. NFC.

[Peter Collingbourne via cfe-commits]

On Wed, Sep 7, 2016 at 6:44 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> On 7 Sep 2016 6:23 pm, "Peter Collingbourne" <peter at pcc.me.uk> wrote:
>
> pcc marked 4 inline comments as done.
>
> ================
> Comment at: lib/CodeGen/CGVTables.cpp:588
> @@ +587,3 @@
> +        if (auto *F = dyn_cast<llvm::Function>(Cache))
> +          F->setUnnamedAddr(llvm::GlobalValue::UnnamedAddr::Global);
> +        Cache = llvm::ConstantExpr::getBitCast(Cache, CGM.Int8PtrTy);
> ----------------
> rsmith wrote:
> > Do you have any idea why we're doing this? It looks wrong to me. These
> ABI entry points are exposed and could certainly have their addresses taken
> and used in this translation unit.
> I introduced this in D18071. Although a translation unit can take the
> address of one of these functions, that would involve declaring a function
> with a reserved name, so I believe we'd be allowed to impose restrictions
> such as `unnamed_addr` on the address.
>
>
> These are declared by <cxxabi.h>, and thus presumably intended to be
> useable by programs, so I'm not convinced that reasoning applies.
>

cxxabi.h isn't part of the standard, is it? So whatever it does shouldn't
have an effect on the standard.


> Do we gain anything from this?
>

Not at present (the relative ABI is the only user I know of and that isn't
fully implemented yet on trunk), although something like this may be
required if we ever fully implement the relative ABI.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160907/5289d28e/attachment.html>