Re: [Gomp-discuss] Somethings to think about ....

[Steven Bosscher]

Op ma 10-03-2003, om 15:53 schreef Lars Segerlund:
> >>  As for the tasks ahead, I think it's not to hard to use the framework 
> >>in the paper to target the GENERIC tree's ( which is the most resonable 
> >>form to target IMHO ). The algoritms for an rather good implementation 
> >>seem's to all be there, and the nice part is that if we extend the 
> >>pragma handling and add a -fgomp to gcc, we should be able to leave most 
> >>of the regulat stuff in place.
> > 
> > 
> > I would prefer -fopenmp :-)
> > 
> 
>   Why do you come up with all the good names :-) ... I do agree.
> 

I've reconsidered... What about -fopen(mp), or -freopenmp, or... :-)


> > Do you have a plan we can discuss on some mailing list?
> 
>   As for a plan, do you mean something concrete ?
> 
>   I would then suggest that we investigated what is needed to enhance 
> GENERIC enough to support the form of Diego's paper, since there is a 
> set of algorithms to support this.
> 
>   I was more thinking that we could have a discussion about what the 
> plan should be :-) ... since we don't have a plan yet.
> 
>   Basicly I think along these lines,
> 
>    1. the lib is trivial to do, and a stub might as well be enough to 
> enable other areas of work to progress.
> 
>    2. the tree modifications are not that hard, but have to be carefully 
> planned in order to be efficient and extendable. Still they have to be done.

Agreed.  We're doing IR design here, it's the kind of stuff you should
do "right" on the first try...  I have never seen an IR with concurrency
awareness; Diego's probably the only one of us who has???


>    3. the algorithms used for the concurrency can be tested on the 
> tree's when these are done, without a proper front and backend, this 
> might even be a very nice thing to do in order to get some proper 
> testing done. If this phase is basicly 'bug' free I think a lot of later 
> work is spared.

I still don't see how you want to test without a front end, but that
could be just me...

>    4. at this point it should be about time to figure how to interface 
> with gcc n the most 'non intrusive' manner. And as I understand it, 
> there could be two routes to this, the first is to make gcc ignore ( 
> remove ) the parallell part's of the tree if not -fopenmp is given, and 
> the second is to enable the extra 'concurrency aware' code if the 
> -fopenmp ( or replace parts of gcc with concurrency aware code ). ( I 
> don't know if it get's through what I mean, but it's basicly a tightly 
> knit implementation vs. a loosely knit implementation ).

We should *never* end up with "concurrent tree_codes" in the middle end,
because if -fopenmp is not set, we would ignore all the OMP pragmas.


>    5. When this is done, it would be reasonable to start doing the code 
> generation. ( I haven't given this any thoughts ).

My question here is: How "thread-safe" is RTL?  The tree optimizers are
no problem (we plan to make them concurrency-aware, after all :-), but
what havoc can the RTL optimizers bring upon us?


>    6. Front end work making gcc take advantage of the parallell trees 
> should be the last thing to get the compiler working, and at this point 
> we should have a working implementation.

Ref. (3).  I really hope Seb. comes up with a nice __builtin_pragma
implementation *before* we start hacking the middle end.


>   So I should think we would need a specification of what to do with the 
> trees and what we need to represent, from there we only have to code a 
> lot. ( :-D ).

The coding is the *easy* part :-D

Greetz
Steven