This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: backwards threader cleanups
- From: Jeff Law <law at redhat dot com>
- To: Aldy Hernandez <aldyh at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 1 Sep 2017 16:11:35 -0600
- Subject: Re: backwards threader cleanups
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 29B6D81DF2
- References: <CAGm3qMWs2uhGOcSuKDpujmzy0X3x_8omutkkuvvua4kpoo=rWg@mail.gmail.com>
On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
> Hi.
>
> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
> The main gist of the patch is making the path vectors live in the
> heap, not GC. But I also cleaned up some comments to reflect reality,
> and renamed VAR_BB which could use a more meaningful name. Finally, I
> abstracted some common code to
> register_jump_thread_path_if_profitable() in preparation for some
> upcoming work by me :).
>
> Tested on x86-64 Linux.
It looks like you dropped a level of indirection for path in
profitable_jump_thread_path and perhaps others that push blocks onto the
path? Does your change from having the vectors in the GC space to the
heap also change them from embeddable vectors to a space efficient
vector? It has to for this change to be safe.
See the discussion in vec.h
I don't recall any inherent reason we use the embedded vector layout.
It's the default which is probably why it's used here more than anything.
Otherwise the change looks good. I think you just to make sure you're
not using the embedded layout. Which I think is just a different type
when you declare the vec.
Jeff