This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] cleanup gcse.c:canon_modify_mem_list
- From: Jeff Law <law at redhat dot com>
- To: Nathan Froyd <froydnj at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 04 Apr 2011 12:01:09 -0600
- Subject: Re: [PATCH] cleanup gcse.c:canon_modify_mem_list
- References: <20110404014451.GA16239@nightcrawler>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/03/11 19:44, Nathan Froyd wrote:
> The patch below converts gcse.c:canon_modify_mem_list to hold VECs
> instead of EXPR_LIST rtxes. I am ambivalent about the use of VECs in
> canon_modify_mem_list; they will waste some memory compared to the
> linked list scheme present before, though I'm not sure how much. It
> would depend on the average chain length, etc. I'm happy to use an
> linked list datastructure instead, allocated out of an
> alloc_pool (better statistics!) or even gcse's private obstack if folks
> think that would be better. Moving things out of GC memory and
> eliminating a use of EXPR_LIST has to be considered a good thing,
> though...
I've got no strong opinions on all this stuff -- except that blindly
moving stuff out of GC memory isn't necessarily a good thing. It really
depends on the lifetime of the objects.
Assuming the memory list stuff in gcse doesn't have a lifetime outside
of GCSE and is thus easily tracked, then I've got no fundamental
objection to the change.
>
> Doing this required addressing an odd little comment in
> record_last_mem_set_info:
>
> if (CALL_P (insn))
> {
> /* Note that traversals of this loop (other than for free-ing)
> will break after encountering a CALL_INSN. So, there's no
> need to insert a pair of items, as canon_list_insert does. */
> canon_modify_mem_list[bb] =
> alloc_INSN_LIST (insn, canon_modify_mem_list[bb]);
> bitmap_set_bit (blocks_with_calls, bb);
> }
>
> This is all well and good, except that the only real traversal of
> canon_modify_mem_list (compute_transp) doesn't check for CALL_INSNs.
It's possible (likely?) the implementation changed over time and the
comment wasn't properly updated. Unfortunate, but it does happen.
> + canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
> + last_basic_block);
nit; You're missing some whitespace here (after the VEC).
OK. Please install,
Thanks,
Jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNmgdkAAoJEBRtltQi2kC7QagH/AkchggJ4C7SU2AasolDyQqn
tcQowd5zBmiYFujY9+UgIL6Wh6AVU/Ls452c96MVKKWcDi8kIW0y3tzlls5yYbKW
/XtvuzPU9zhya672mjTNktD3mPFj4qKtAO7PsjCh375uvkSknSXCAP9B5O9nQPbR
BdaaAHv4gLgrpIokFTxk5455/7BGMCNJ0/O91PR4Jyithc2wZsz6Me4AFg+aMZG/
t+Vq7+6D5kALiXrrn2UNzrGefE6i6HdbacP6drOaDI1XNmI8Se4NgiE/JQfkvKty
1i4MVGW2IJrMax7fCKLhIRErQxEgfGQVfOLk5WkQXSzxfvILLu1bkdTTLKTr6t0=
=tTk7
-----END PGP SIGNATURE-----