This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/5 ][P1] [PR tree-optimization/71437] Use a dominator order walk rather than random for VRP threading
- From: Trevor Saunders <tbsaunde at tbsaunde dot org>
- To: Jeff Law <suzanne dot jeff dot law at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 17 Mar 2017 08:38:49 -0400
- Subject: Re: [PATCH 4/5 ][P1] [PR tree-optimization/71437] Use a dominator order walk rather than random for VRP threading
- Authentication-results: sourceware.org; auth=none
- References: <b035d4f7-6907-2520-34fd-e29d62c4082e@gmail.com>
On Thu, Mar 16, 2017 at 01:17:13PM -0600, Jeff Law wrote:
> +thread_outgoing_edges (basic_block bb, gcond *dummy_cond,
> + class const_and_copies *const_and_copies,
> + class avail_exprs_stack *avail_exprs_stack,
nit picking, but what's the point in the class keyword here?
> + tree (*simplify) (gimple *, gimple *,
> + class avail_exprs_stack *,
> + basic_block))
this could just be pfn_simplify right?
> +private:
> + class const_and_copies *m_const_and_copies;
> + class avail_exprs_stack *m_avail_exprs_stack;
same nit about class here.
> + const_and_copies *equiv_stack = new const_and_copies ();
>
> + hash_table<expr_elt_hasher> *avail_exprs
> + = new hash_table<expr_elt_hasher> (1024);
> + avail_exprs_stack *avail_exprs_stack
> + = new class avail_exprs_stack (avail_exprs);
None of these ever live passed the end of the function right? so why not
put the objects on the stack?
> delete equiv_stack;
> + delete avail_exprs_stack;
this misses cleaning up the hash table right? Though of course its all
unneeded if these objects are on the stack.
Hoep that's useful.
Trev