Stackmaps liveness analysis can determine RIP is live

[Quuxplusone]

Bugzilla Link	PR21266
Status	NEW
Importance	P normal
Reported by	kmod@dropbox.com
Reported on	2014-10-13 17:48:01 -0700
Last modified on	2014-10-15 06:11:47 -0700
Version	trunk
Hardware	PC Linux
CC	atrick@apple.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	rip.ll (741 bytes, application/octet-stream)
Blocks
Blocked by
See also

Created attachment 13199
Test case -- reproduce with "llc rip.ll"

Here's a snippet of the machine ir before stackmaps liveness analysis:

BB#1: derived from LLVM BB %1, Align 4 (16 bytes)
    Live Ins: %RBP
    Predecessors according to CFG: BB#1 BB#0
        PATCHPOINT 30697712, 13, 8441600, 0, 0, <regmask>, %RSP<imp-def>, %RAX<imp-def,dead>, ...
        %RAX<def> = MOV64rm %RIP, 1, %noreg, <ga:@edgecount>, %noreg; mem:LD8[@edgecount]
        %RAX<def,tied1> = INC64r %RAX<kill,tied0>, %EFLAGS<imp-def,dead>
        CMP64ri32 %RAX<kill>, 10001, %EFLAGS<imp-def>
        JL_4 <BB#1>, %EFLAGS<imp-use,kill>
    Successors according to CFG: BB#2(4) BB#1(124)

And here's what happens in stackmap liveness:

********** COMPUTING STACKMAP LIVENESS: f_e1_1 **********
[snip]
****** BB  ******
   Live Registers: %RBP %EBP %BP %BPL
   JL_4 <BB#1>, %EFLAGS<imp-use,kill>
   Live Registers: %RBP %EBP %BP %BPL %EFLAGS
   CMP64ri32 %RAX<kill>, 10001, %EFLAGS<imp-def>
   Live Registers: %RBP %EBP %BP %BPL %RAX %EAX %AX %AL %AH
   %RAX<def,tied1> = INC64r %RAX<kill,tied0>, %EFLAGS<imp-def,dead>
   Live Registers: %RBP %EBP %BP %BPL %RAX %EAX %AX %AL %AH
   %RAX<def> = MOV64rm %RIP, 1, %noreg, <ga:@edgecount>, %noreg; mem:LD8[@edgecount]
   Live Registers: %RBP %EBP %BP %BPL %RIP %EIP %IP
   PATCHPOINT 30697712, 13, 8441600, 0, 0, <regmask>, <regliveout>, %RSP<imp-def>, %RAX<imp-def,dead>, ...
[snip]
llc: /opt/kmod_unenc/pyston_deps/llvm-
test/lib/CodeGen/TargetRegisterInfo.cpp:124: const llvm::TargetRegisterClass*
llvm::TargetRegisterInfo::getMinimalPhysRegClass(unsigned int, llvm::EVT)
const: Assertion `BestRC && "Couldn't find the register class"' failed.

It looks like the stackmaps liveness analysis is seeing the RIP-relative load
as a usage of %RIP that establishes its liveness, which causes the stackmap
emission to fail.

[Quuxplusone]

Attached rip.ll (741 bytes, application/octet-stream): Test case -- reproduce with "llc rip.ll"

[Quuxplusone]

LivePhysRegs should not be tracking reserved registers. This should be a simple fix, but Juergen may want to verify that current stackmap users (WebKit) don't expect any reserved registers in the live set (they should know better than to clobber SP/FP). We may want to unconditionally add the base pointer to the stackmap live set if hasBasePointer() is true.

In general, if the register is reserved per the platform ABI, we should not need to add it to the stackmap. If it is reserved for LLVM internal use, then we probably should add it.