Re: OMP_ATOMIC expand/gimplify changes

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

> > +  bsi = bsi_after_labels (store_bb);
> > +  stmt = bsi_stmt (bsi);
> > +  if (TREE_CODE (stmt) != GIMPLE_MODIFY_STMT)
> > +    return false;
> > +  bsi_next (&bsi);
> > +  if (TREE_CODE (bsi_stmt (bsi)) != OMP_ATOMIC_STORE)
> > +    return false;
> > +
> > +  if (!operand_equal_p (GIMPLE_STMT_OPERAND (stmt, 0),
> > +		 		 		 stored_val, 0))
> > +    return false;
> 
> Instead of this blind structural check of statements, perhaps it would
> better to use data flow to pick the statements?  This is not a problem
> today, but in the future it may happen that we have code motion passes
> before OMP expansion.  In which case, extraneous code may have been
> inserted in the middle of this sequence.  This would make us give up
> too soon, even if we *could* reconstruct the statements to emit a
> proper atomic fetch.
> 
> I don't think this is terribly important for now, but we should think
> about a better expansion strategy for the future.  Any ideas?  For
> now, we could just add a FIXME here for future reference.

I thought about this too; unfortunately, as expansion needs to work
also without SSA form, this is somewhat complicated.

> > +get_addr_dereference_operands (tree stmt, tree *addr, int flags,
> > +                                                      tree full_ref,
> > +                                                       HOST_WIDE_INT offset, HOST_WIDE_INT size,
> > +                                                       bool recurse_on_base)
> 
> Why was this needed?  It's not clear to me why you extracted this code
> out of get_indirect_ref_operands.

We use this function to set up the virtual operands of OMP_LOAD, as it
has the address of the memory reference as an operand, not the memory
reference itself (the same as OMP_ATOMIC).

Zdenek