[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

["tejohnson at google dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432

--- Comment #21 from Teresa Johnson <tejohnson at google dot com> ---
On Tue, Oct 7, 2014 at 11:08 AM, Jeff Law <law@redhat.com> wrote:
> On 10/04/14 13:29, Teresa Johnson wrote:
>>>
>>> Jeff, what is intended here - should we not be threading both of these
>>> paths?
>>
>>
>> I have a patch to make the mark_threaded_blocks checking of paths work
>> regardless of the ordering of paths in the vec. This fixes the
>> failure.
>
> This seems like a better solution.  It'll decrease unnecessary block
> copying.

Ok, great. The patch I posted had a bug I introduced when cleaning it
up that was caught by my LTO profiledbootstrap in that I wasn't
resetting the e->aux pointer back to NULL when canceling the jump
thread. I am kicking off the testing again and should hopefully have a
final patch to send to gcc-patches later today.

>
>>
>> The other approach is whenever we finish threading a path, go through
>> the vec of remaining paths and update the edges for any that have been
>> affected by the threading and that should instead include the
>> duplicated edges.
>
> That'd probably work too, but I suspect there's not much, if any, benefit to
> keeping both paths.

Yeah, in this case the extra threading worked from a correctness
standpoint but doesn't make sense from a logical or performance
standpoint.

> I typically have to draw out the CFG and the intermediate steps to gain clarity into the desired result and there's not enough info here to do that.

I'm glad I'm not the only one who has to draw it out every time!

Thanks,
Teresa

>
> Jeff