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

[Tom Roeder]

On Wed, May 21, 2014 at 3:05 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>> Of course, this all works best under LTO, since the tables can all be
>> written together. Otherwise, a given function might have more than one
>> associated jumptable function. That would still work, since the two
>> symbols would be in different tables, and both would still resolve
>> their jumps to the same function.
>
> Assuming the address of the function is not compared, right?

Right. Any code that assumes pointer equality between modules for a
function declared as jumptable in both modules will fail.  Now that I
think about it, this is true even without putting jumptable into two
separate modules, and without adding jumptable to external functions.

For example, consider two modules: module M1 declares @f as a normal
undefined function, and module M2 defines @f as jumptable. If M2
passes a function pointer for @f to M1, it will pass @f_JT. @f_JT will
still work perfectly as a function pointer for @f except it will
happen not to have the same function pointer value as @f. So, equality
comparisons with @f will fail.

Is this OK?

This is related to an exchange between Nick and me earlier in this review:

>>> What's the right behaviour if you link together two modules where a
>>> function is not "jumptable" in one but is in the other? Is it safe to apply
>>> "jumptable" to a module that didn't have it? It looks like not.
>>
>>
>> I believe it is safe to apply jumptable to any function that didn't
>> have it, since the resulting function acts like the original function
>> in all ways except having a different function pointer (that goes
>> through a single jump instruction in the jump table). And the code
>> rewrites all such function pointers at CodeGen time, so after the IR
>> modules are merged. I don't see any correctness problems in adding
>> this annotation unless the code is making assumptions about the
>> relative location of code wrt the function pointer. Are such
>> assumptions allowed for IR?
>
>
>We don't optimize comparisons between function pointers away, but we don't preserve particular ordering or sizes of functions. I think your change is fine.

However, that doesn't directly address the question you brought up. I
haven't seen this problem in any of the large amounts of code I've
compiled with this kind of transformation in place, but admittedly, I
was using LTO, so almost all the code was being compiled as a single
module. Can we simply make this part of the semantics of jumptable? It
means you can't count on function pointer identity for that function.
I could document this in the LangRef description, for example.

Thanks,

Tom