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: [gomp] More IL work


On Tue, Jul 19, 2005 at 06:06:53PM +0200, Sebastian Pop wrote:

> Why too early?  Their development is orthogonal to OpenMP.  It will
> just use the existing infrastructure for generating parallel code.
> 
Nope, it's very much related.  They will likely need to call into
the IL infrastructure for generating the OpenMP directives.  They
won't be able to inject a #pragma in the code (we cannot do
source-to-source easily).  They will either want to generate
GOMP_PARALLEL_* IL or call the APIs directly.  All of which is
still very much in development.

In a sense, it may be an advantage to the development of the
general framework.  But the current objective is OpenMP
code generation, not a general parallelization framework.

> The aim is to split a loop nest into chunks and to distribute these
> into several threads, so the target will be data parallel code with
> calls to libgomp.
> 
Exactly (see above).

> I was thinking to put their contributions into autovect only because I
> will work on the loop fission there, and that we have some more bits
> on the data dependence tester.  But for what they want to do the
> existing data dep of mainline/gomp is ok.
> 
The data dependency analysis, maybe.  The rest will be changing
under their feet every couple of weeks.  If they can live with
that, then OK.

> > How about a sub-branch?
> 
> Their changes won't be too big, one or two new files: a new pass.
> Then with time I think they will be interested in having their pass
> triggered only for some loops and then they will probably contribute
> also to the general goal of gomp.  So I won't scare them away by
> asking them to contribute to general infrastructure.
> 
They *will* need new general infrastructure.  We've got nothing
right now.  But, I guess if they can live with a shifting
framework, then I don't mind too much.


Diego.


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