<div dir="ltr">I think it's a little scary to assume things about LLVM's x86 code generation. I haven't really finished the codegen side of the change, but I'm pretty sure in it's current state it will emit extra loads and stores, even if they are unnecessary.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 6:28 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Wed, Apr 02, 2014 at 05:28:04PM -0700, Tom Roeder wrote:<br>
> On Fri, Mar 21, 2014 at 1:46 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>>wrote:<br>
><br>
> > On Fri, Mar 21, 2014 at 12:54:07PM -0700, Tom Roeder wrote:<br>
> > > On Fri, Mar 21, 2014 at 12:15 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>><br>
> > wrote:<br>
> > > >> The way I've implemented it (see the patch I sent to llvm-commits<br>
> > > >> yesterday), it's not just metadata: the intrinsic lowers to the<br>
> > > >> jumptable entry code given above. The CFI pass then generates a<br>
> > > >> function for each jump table; the function consists solely of these<br>
> > > >> intrinsic calls.<br>
> > > ><br>
> > > > Well, the intrinsic you proposed has no effect on the caller and has<br>
> > > > non-local effects on other specified functions. I'm not aware of any<br>
> > other<br>
> > > > intrinsic with similar behavior.<br>
> > ><br>
> > > I agree that it's not very similar to other intrinsics. But I don't<br>
> > > exactly follow these statements. There are definitely intrinsics that<br>
> > > have no effect on the caller, like llvm.var.annotation.<br>
> ><br>
> > Yes but the purpose of such intrinsics is to communicate information about<br>
> > a specific value that may have an effect on analysis, optimization or code<br>
> > generation for that caller. On the other hand, the intrinsic you are<br>
> > proposing<br>
> > has nothing to do with the caller.<br>
> ><br>
> > > And AFAIK,<br>
> > > there is no non-local behavior: all the intrinsic does is lower to the<br>
> > > labeled jump instruction; the changes to address-taken functions are<br>
> > > done separately by the CFI pass. Note that in the patch I sent, the<br>
> > > intrinsic only takes one argument: the function to jump to. Are there<br>
> > > other effects in this case?<br>
> ><br>
> > The non-local effect is that the intrinsic describes the definition of a<br>
> > function in the global scope. Normally such definitions come from top-level<br>
> > entities.<br>
> ><br>
> > > So, maybe it would be better to call it something like<br>
> > > @llvm.unconditional.jump(i8*)? I could then make it only lower to the<br>
> > > jump and add an intrinsic that lowered to a function label as well.<br>
> ><br>
> > I'd imagine that might present more problems. For example, if you used<br>
> > either intrinsic in the middle of a regular function the behavior would not<br>
> > necessarily be well defined. It would be necessary to carefully document<br>
> > where and how these intrinsics may be used.<br>
> ><br>
><br>
> Taking these considerations into account, I propose this:<br>
><br>
> Jump functions created for the jump table are actual functions, marked with<br>
> a new jumptable attribute, as well as naked and noreturn and optnone. Each<br>
> table is put in a special section using the section attribute, and<br>
> alignment of these functions is done using the align attribute. The<br>
> combination of these attributes means that the function has no preamble or<br>
> postamble, so it consists of exactly a global function label and its<br>
> instructions.<br>
><br>
> Then I think it would make sense to create an intrinsic like<br>
> llvm.jumptable.instr(i8*) that would be a placeholder for an unconditional<br>
> jump. I can add code to the verifier that insists on two conditions:<br>
><br>
> 1. functions marked as jumptable must have exactly two instructions: an<br>
> llvm.jumptable.instr followed by a unreachable.<br>
> 2. llvm.jumptable.instr can only occur in a jumptable function.<br>
><br>
> I think this handles the problem of using llvm.jumptable.instr in normal<br>
> functions: that isn't allowed. And I think it deals with the problems of<br>
> non-local behavior by making functions out of the things that really are<br>
> functions. Each entry in the jump table really is a function, albeit a<br>
> rather strange one, so it should look like a function at the IR level.<br>
><br>
> In other words, this change would add a new attribute that marks a very<br>
> specialized kind of function and an intrinsic that can only occur in this<br>
> kind of function.<br>
><br>
> What do you think?<br>
<br>
</div></div>I think you might be close.<br>
<br>
The llvm.jumptable.instr intrinsic you have proposed is similar to the<br>
'musttail' call marker that Reid (cc'd) is working on in [1]. That marker will<br>
also have verifier support. I think it might be reasonable to require the<br>
code generator to emit the body of a function containing only a 'musttail'<br>
function call as a single branch instruction. Then you could emit such<br>
functions in the jump table section.<br>
<br>
Reid, what do you think?<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Peter<br>
<br>
[1] <a href="http://llvm-reviews.chandlerc.com/D3240" target="_blank">http://llvm-reviews.chandlerc.com/D3240</a><br>
</font></span></blockquote></div><br></div>