Re: scheduler queue flush (was Re: [gcc-15 0/3] RISC-V improve stack/array access by constant mat tweak)

[Jeff Law <jeffreyalaw@gmail.com>]

On 3/21/24 8:36 AM, Vineet Gupta wrote:
> 
> 
> On 3/18/24 21:41, Jeff Law wrote:
>>
>> On 3/16/24 11:35 AM, Vineet Gupta wrote:
>>> Hi,
>>>
>>> This set of patches (for gcc-15) help improve stack/array accesses
>>> by improving constant materialization. Details are in respective
>>> patches.
>>>
>>> The first patch is the main change which improves SPEC cactu by 10%.
>> Just to confirm.  Yup, 10% reduction in icounts and about a 3.5%
>> improvement in cycles on our target.  Which is great!
>>
>> This also makes me wonder if cactu is the benchmark that was sensitive
>> to flushing the pending queue in the scheduler.  Jivan's data would tend
>> to indicate that is the case as several routines seem to flush the
>> pending queue often.  In particular:
>>
>> ML_BSSN_RHS_Body
>> ML_BSSN_Advect_Body
>> ML_BSSN_constraints_Body
>>
>> All have a high number of dynamic instructions as well as lots of
>> flushes of the pending queue.
>>
>> Vineet, you might want to look and see if cranking up the
>> max-pending-list-length parameter helps drive down spilling.   I think
>> it's default value is 32 insns.  I've seen it cranked up to 128 and 256
>> insns without significant ill effects on compile time.
>>
>> My recollection (it's been like 3 years) of the key loop was that it had
>> a few hundred instructions and we'd flush the pending list about 50
>> cycles into the loop as there just wasn't enough issue bandwidth to the
>> FP units to dispatch all the FP instructions as their inputs became
>> ready.  So you'd be looking for flushes in a big loop.
> 
> Here are the results for Cactu on top of the new splitter changes:
> 
> default	: 2,565,319,368,591
> 128	: 2,509,741,035,068
> 256	: 2,527,817,813,612
> 
> I've haven't probed deeper in generated code itself but likely to be
> helping with spilling
Actually, I read that as not important for this issue.  While it is 50b 
instructions, I would be looking for something that had perhaps an order 
of magnitude bigger impact.    Ultimately I think it means we still 
don't have a good handle on what's causing the spilling.  Oh well.

So if we go back to Robin's observation that scheduling dramatically 
increases the instruction count, perhaps we try a run with 
-fno-schedule-insns -fno-schedule-insns2 and see how the instruction 
counts compare.


Jeff