On 3/28/19 2:55 AM, Richard Biener wrote:
> On Wed, Mar 27, 2019 at 4:26 PM Jeff Law <l...@redhat.com> wrote:
>>
>> On 3/27/19 8:36 AM, Jakub Jelinek wrote:
>>> On Sun, Mar 24, 2019 at 09:20:07AM -0600, Jeff Law wrote:
>>>> However, I'm increasingly of the opinion that MIPS targets need to drop
>>>> off the priority platform list. Given the trajectory I see for MIPS
>>>> based processors in industry, it's really hard to justify spending this
>>>> much time on them, particularly for low priority code quality issues.
>>>
>>> Besides what has been discussed on IRC for the PR89826 fix, that we really
>>> need a df_analyze before processing the first block, because otherwise we
>>> can't rely on the REG_UNUSED notes in the IL, I see some other issues, but I
>>> admit I don't know much about df nor regcprop.
>> RIght. I plan to commit that today along with the test reordering you
>> pointed out.
>>
>>>
>>> 1) the df_analyze () after every (successful) processing of a basic block
>>> is IMHO way too expensive, I would be very surprised if df_analyze () isn't
>>> quadratic in number of basic blocks and so one could construct testcases
>>> with millions of basic blocks and at least one regcprop change in each bb
>>> and get at cubic complexity (correct me if I'm wrong, and I'm aware of the
>>> 95% bbs you said won't have any changes at all)
>> I'm going to look this further today.
>
> Look at
> https://gcc.opensuse.org/gcc-old/c++bench-czerny/random/random-performance-latest
> and you'll see multiple testcases with 'hard reg cprop' >10% compile-time.
> It's indeed a hog for no good reason.
I stand corrected. That's really a surprise. I looked at today's
report and don't see anything over 1%, so Jakub's improvements really
helped.
