[PATCH] Reduction support for parloop, OMP_ATOMIC Changes

Zdenek Dvorak rakdver@kam.mff.cuni.cz
Mon Sep 24 18:25:00 GMT 2007


Hello,

> On Mon, Sep 24, 2007 at 05:10:39PM +0200, Razya Ladelsky wrote:
> > Now the testsuite zipped file was corrupted...
> > This is the final patch and testsuite directory :)
> 
> Can you please explain why exactly you want to avoid lowering
> OMP_ATOMIC early?  This OMP_ATOMIC_LOAD/OMP_ATOMIC_STORE
> separation looks terribly fragile to me.

what do you find fragile about it?  It is exactly the same concept as is
used for many other OMP codes (having OMP_RETURN and OMP_CONTINUE for
OMP_FOR etc.).

> What's wrong with just
> emitting __sync etc. immediately when autoparallelizing?
> You could either create OMP_ATOMIC and gimplify that there,
> or you could perhaps tweak the OMP_ATOMIC gimplifiers so that
> they are usable from both OMP_ATOMIC gimplification and the autopar
> code.

the code created by gimplification would require updating cfg (because
of gimplify_omp_atomic_pipeline), and also changes to make the
gimplifier update SSA form correctly.  While it is certainly possible to
hack over these complications, the proposed solution (postponing the
expansion to omp_expand, so that autoparallelization can just use
OMP_ATOMIC codes without need for any special handling) seems much
cleaner to me.

Zdenek



More information about the Gcc-patches mailing list