This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/5 ][P1] [PR tree-optimization/71437] Use a dominator order walk rather than random for VRP threading


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]