[PATCH] Add a jumptable attribute and support for creating jump-instruction tables

[Rafael Espíndola]

>> At the llvm level such a transformation would only be valid if the
>> function was marked with unnamed_addr. You should probably check for
>> that and have a clang option that adds unnamed_addr to every function.
>
> I'm not sure what "check for that" means in this case. In my example,
> the declaration of @f in M1 would need to be marked unnamed_addr based
> on whether or not M2 had a definition @f with jumptable, and that's
> something that's not known when M1 is compiled.

Which is why I suggested a clang option that would add unnamed_addr to
every function. Declaration or not.

> It wouldn't be hard to add a clang option to do this, but even that's
> technically not sufficient, since it could still cause problems with
> modules compiled without the flag or compiled with a different
> compiler.

Well. The reasoning is that if the user says that a function
declaration is unnamed_addr and has another file where that address is
significant he will get undefined behaviour.

> I think this shows that jumptable really does affect the
> ABI, like Nick suggested. I don't know if this kind of pointer
> equality is formally guaranteed at that level, however. Do you know?

It is guaranteed, except for unnamed_addr. How about just requiring
that jumptable can only be added to functions that also have
unnamed_addr?

> AFAICT, this is equivalent to marking a function as unnamed_addr, then
> passing its function pointer out to external code. That compiles in
> IR, though I don't know if that's a bug or not, since it depends on
> the answer to my ABI question. :)
>
> Thanks,
>
> Tom

Cheers,
Rafael