[llvm-commits] [llvm][PATCH][Review Requested] Reserve X86 stack registers to avoid assertion failure(s)

[Gurd, Preston]

Thanks very much, Jakob! Here is a revised and greatly simplified patch, as per your suggestion.

This patch marks the X86 floating point stack registers ST0-ST7 as reserved in order to avoid assertion failures in the register scavenger. The assertion failures were "Bad machine code: Using an undefined physical register" and "Bad machine code: MBB exits via unconditional fall-through but its successor differs from its CFG successor!".

Please review.

Thanks,

Preston


From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk]
Sent: Monday, April 30, 2012 8:14 PM
To: Gurd, Preston
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm][PATCH][Review Requested]


On Apr 30, 2012, at 3:09 PM, "Gurd, Preston" <preston.gurd at intel.com<mailto:preston.gurd at intel.com>> wrote:


The problem which we are trying to solve is that when we enable register scavenging for X86, the register scavenger sees X87 stack registers (which are unallocatable)  and then triggers an assertion failure saying "Using an undefined physical register". We want to ignore unallocatable registers in the registers as per the patch that you committed last July (r136541). That patch was reverted because it apparently negatively affected ARM. We want to ignore unallocatable registers for X86 so that we can use the register scavenger which in turn we need for post RA scheduling for Intel Atom.

Actually, I think this is exposing a real problem. The ST registers can't be treated as normal unallocatable registers because they are really stack positions. This means that the PostRA scheduler can't properly reason about their dependencies either.

I would prefer if the ST registers were reserved. Then the scheduler would know to leave them alone.

The ST registers are also used before register allocation to pass fixed stack parameters to and from inline assembly. Previously, reserving the ST registers broke some tests in inline-asm-fpstack.ll because of missing dead flags, but that seems to have been fixed.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120501/6cee98e0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reserve_stN.patch
Type: application/octet-stream
Size: 733 bytes
Desc: reserve_stN.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120501/6cee98e0/attachment.obj>