[patch i386]: Combine memory and indirect jump

Jeff Law law@redhat.com
Tue Jun 17 19:26:00 GMT 2014


On 06/13/14 10:59, Kai Tietz wrote:
> 2014-06-13 17:58 GMT+02:00 Jeff Law <law@redhat.com>:
>> On 06/13/14 09:56, Richard Henderson wrote:
>>>
>>> On 06/13/2014 08:36 AM, Jeff Law wrote:
>>>>
>>>> So you may have answered this already, but why can't this be a combiner
>>>> pattern?
>>>
>>>
>>> Until pass_duplicate_computed_gotos, we (intentionally) have a single
>>> indirect
>>> branch in the entire function.  This vastly reduces the size of the CFG.
>>
>> Ah, the factoring bits.  Should have known.
>>
>>
>>>
>>> Peep2 is currently running before d_c_g, so currently Kai can't solve this
>>> problem in peep2.
>>>
>>> I don't think peep2 should run after sched2, but I'll bet we can reorder
>>> things
>>> a bit so that d_c_g runs before peep2.
>>
>> Yea, seems worth a try.
>>
>> jeff
>>
>
> Well, I tested to put the second sched2 pass before the sched2 pass.
> That works in general.  There are just some opportunties which weren't
> caught then.  I attached a sample, which demonstrates that pretty
> well.  I noticed that I had to put that pass behind reload blocks was
> necessary for better hit-rate of the peephole optimization.
So can you tell us why this sample code misses opportunities?  Otherwise 
we have to dig into it ourselves to tease out that information.

I think we're zeroing in on a path to move d_c_g before peep2, but I'd 
like to have a clearer understanding of why we'd still be missing 
opportunities.  If we can avoid running peep2 twice, that'd be good.

jeff




More information about the Gcc-patches mailing list