This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch i386]: Combine memory and indirect jump


2014-06-17 21:26 GMT+02:00 Jeff Law <law@redhat.com>:
> 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

Hi Jeff,

I just did retest my testcase with recent source. I can't reproduce
this missed optimization before sched2 pass anymore.  I moved second
peephole2 pass just before split_before_sched2 and everything got
caught.

To remove first peephole2 pass seems to cause weaker code for
impossible pushes, etc

Nevertheless it might be a point to make this new peephole instead a
define_split?  I admit that this operation isn't a split, nevertheless
we would avoid a second peephole pass.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]