[llvm-commits] [cfe-commits] [PATCH] Potential fix for PR9614

Peter Collingbourne peter at pcc.me.uk
Wed Oct 12 14:16:19 PDT 2011


On Tue, Oct 11, 2011 at 04:02:29PM -0700, Eli Friedman wrote:
> >> >  (Granted, that's still a bit messy, but I can't
> >> > think of a particularly better solution... the only other thing I can
> >> > think of is abusing aliases somehow to get the desired semantics,
> >> > using a special kind of linkage.  Possibly more localized, but aliases
> >> > can get messy.)
> >
> > I considered using aliases for this, but aliases don't really capture
> > the semantics of the call as well as a call attribute would do, and
> > the attribute seems to be simpler for frontends for other languages
> > which need this same functionality to emit.  So, less messy IMHO.
> 
> In some sense, it's not really a property of the call, though... for
> example, consider the following:
> 
> extern void __foo_alias(void) __asm ("foo");
> inline void foo() {
>   void (*ptr)(void) = __foo_alias;
>   ptr();
> }
> 
> (Granted, I doubt there's any real-world code that actually does that,
> but I'm sure it works in gcc.)

You're right to say that that it isn't a property of the call, at least
at the C level.  It seems more like a property of the reference to
"foo" (i.e. whether the reference is via an asm label or not).

I don't know if we should use aliases to represent this property
though.  Perhaps a cleaner solution would be to introduce a new
Constant kind which represents a GlobalValue reference via an asm
label.  For global variables and undefined and non-available_externally
functions, this could constant fold to the GlobalValue itself.

On the other hand I think it's important to stay realistic.  I don't
think it's worth worrying about code like that unless we actually
encounter it.  And even if we were to implement support for code
like that, the external attribute seems like a useful thing for the
IR to have, and could (perhaps) serve as a canonical form for direct
calls via asm labels.

Thanks,
-- 
Peter



More information about the llvm-commits mailing list