[PATCH] Allow the register scavenger to spill multiple registers

Richard Sandiford rsandifo at linux.vnet.ibm.com
Wed Mar 27 03:03:25 PDT 2013


Hal Finkel <hfinkel at anl.gov> writes:
> ----- Original Message -----
>> From: "Richard Sandiford" <rdsandiford at googlemail.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>,
>> "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
>> Sent: Tuesday, March 26, 2013 6:40:05 AM
>> Subject: Re: [PATCH] Allow the register scavenger to spill multiple registers
>> 
>> Hal Finkel <hfinkel-uKDnm65ik8M at public.gmane.org> writes:
>> > Please review the attached patch which lets the register scavenger
>> > make
>> > use of multiple spill slots in order to guarantee that it will be
>> > able
>> > to provide multiple registers simultaneously. I intend to use this
>> > capability in the PowerPC backend to handle spills where we need
>> > two
>> > registers (one for indexing and one for transfer) without keeping
>> > an
>> > extra reserved register.
>> 
>> This might have been discussed already, sorry, but: this patch seems
>> to
>> change the behaviour for targets that use something other than a
>> frame
>> index as scavenging spill space.  (E.g. Thumb 1 uses r12, MIPS16 uses
>> t0.)
>> Those targets never called setScavengingFrameIndex() and instead left
>> the ScavengingFrameIndex as -1.  They used saveScavengerRegister to
>> do
>> the saving and restoring.
>> 
>> Targets that don't register a frame index now hit the assert:
>> 
>>   assert(SI < Scavenged.size() &&
>>          "Scavenger slots are live, unable to scavenge another
>>          register!");
>> 
>> before saveScavengerRegister() is called.
>
> I think that I've fixed this in r178073; if you could confirm, or better
> yet, commit a test case, that would be greatly appreciated.

Thanks for the quick fix.  I think the test for whether to push a new
ScavengingInfo was inverted though.  (Patch below.)

I'm afraid I don't have an ARM or MIPS testcase.  I saw this when running
the scavenging tests for an as-yet unsubmitted port; the tests failed after
the initial commit and pass again after the combination of r178073 and the
patch below.

Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: scavenging-range-test.diff
Type: text/x-patch
Size: 580 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130327/0578e68a/attachment.bin>


More information about the llvm-commits mailing list