[PATCH][stackmap] Stackmaps don't modify the heap, but they do read all memory and they may not return normally

[Philip Reames]

LGTM both code wise and motivation.

Philip

On 02/19/2014 07:47 PM, Filip Pizlo wrote:
> Stackmaps, as opposed to patchpoints, are intended for OSR exits, aka deoptimization.  The outcome of executing a stackmap should be one of two things:
>
> - Nothing.  This is the usual outcome, since OSR exits are very rare.
> - Exit (i.e. "unwind") via the client runtime's OSR exit machinery, while recovering the values of the variables passed to the stackmap, and then running arbitrary code that may read/write the entire heap - but only after the caller is no longer on the stack.
>
> The best way to model this is to say that stackmaps are "readonly" but not "nounwind".  I attach a patch that does this.
>
> Prior to this patch, stackmaps are "nounwind" but not "readonly" - i.e. we assume that they may read or write the world, but that they always return normally.  They definitely don't write anything - at least not in a way that is observable to the caller - so "readonly" is appropriate.  However, "readonly" and "nounwind" means, among other things, that if you don't use the return value of the function then the call can be DCE'd.  Stackmap returns void, so it's definitely true that nobody will ever use its return value.  I believe that marking stackmap as "nounwind" is inaccurate even without the "readonly" attribute, since its original customer used it precisely for a custom kind of unwinding.  So, "readonly" but not "nounwind" feels like it most accurately models the way that stackmaps are used.
>
> FWIW, I tested this against the test suite we use for the WebKit FTL JIT, and this doesn't break anything.  I don't have performance numbers, yet - though I'd advocate for this change even if wasn't yet a win since I think it's just good form to accurately model effects.
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140220/0455acde/attachment.html>