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: RFC patch for #pragma ivdep


On Tue, Oct 08, 2013 at 08:51:50AM +0200, Tobias Burnus wrote:
> --- a/gcc/cfgloop.c
> +++ b/gcc/cfgloop.c
> @@ -507,6 +507,39 @@ flow_loops_find (struct loops *loops)
>  	      loop->latch = latch;
>  	    }
>  	}
> +      /* Search for ANNOTATE call with annot_expr_ivdep_kind; if found, remove
> +	 it and set loop->safelen to INT_MAX.  */
> +      if (loop->latch && loop->latch->next_bb != EXIT_BLOCK_PTR
> +          && bb_seq_addr (loop->latch->next_bb))

Why this bb_seq_addr guard?

> +	{
> +           gimple_stmt_iterator gsi;
> +           for (gsi = gsi_start_bb (loop->latch->next_bb);
> +		gsi.bb && gsi.seq && !gsi_end_p (gsi);
> +		gsi_next (&gsi))
> +              {
> +                gimple stmt = gsi_stmt (gsi);
> +		if (gimple_code (stmt) == GIMPLE_COND)

GIMPLE_COND must be the last stmt in a bb.  So, instead of the walk just
do
  gimple stmt = last_stmt (loop->latch->next_bb);
  if (stmt && gimple_code (stmt) == GIMPLE_COND)

Also, not sure if you really want loop->latch->next_bb rather than
look through succs of loop->latch or similar, next_bb is really chaining
of bb's together in some order, doesn't imply there is an edge in between
the previous and next bb and what the edge kind is.

	Jakub


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