[LLVMdev] Thoughts on maintaining liveness information for stackmaps

[Kevin Modzelewski]

Hi all, I've run into a couple bugs recently that affected stackmap
liveness analysis in various ways:
http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live
unnecessarily
http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out
http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out

The first two have nothing to do with stackmaps specifically but just end
up affecting it; the last two will crash the stackmaps code.  I think my
takeaway is that at this late point in the pipeline, the stackmaps liveness
code has to be the main consumer of this information, otherwise these kinds
of bugs/behavior would have been noticed.  So fixing them might mostly be
in the interest of the stackmaps code, and I'm wondering if even if we do
classify these as bugs and fix them, if there would be a runtime cost paid
by non-stackmaps-using code.  I'm also worried that there might be more
than these three bugs and it might be a bit of a losing battle if getting
this perfectly right isn't useful beyond just stackmaps.


So I guess my question is: should we try to fix all these issues, or accept
that there can potentially be some extra registers in the live-outs set
when we get around to emitting the stackmaps section?  (Or another option?)
 By "accepting the possibility", I'm meaning that we could filter out
non-feasible registers like eflags and rip, and consumers would have to
accept that there might be extra registers that are included unnecessarily
(which can already happen).

I created a hacky little patch that simply ignores bogus registers when
doing the liveness calculation:
https://github.com/kmod/pyston/blob/73a1a9897ec649f2249a69d523c820c0d4321786/llvm_patches/0009-Filter-out-extraneous-registers-from-live-outs-like-.patch
Not sure if this is the kind of approach we would like to go with, but so
far in my very limited testing it seems to be ok and at least things don't
crash.  What do you guys think?

kmod
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141013/d0c31533/attachment.html>