[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