* [gomp] OpenMP IL design notes
@ 2005-05-03 20:43 Diego Novillo
2005-05-03 21:05 ` Lars Segerlund
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: Diego Novillo @ 2005-05-03 20:43 UTC (permalink / raw)
To: gcc
I have started working on connecting Dmitry's OpenMP parser to
the middle-end so that we can start generating the basic runtime
calls, which Richard should be posting soon. With any luck, we
should have some basic functionality in a few weeks.
Initially, we will be outlining parallel sections into their own
functions. This is mostly for implementation convenience.
However, long term we are better off incorporating parallel
markers into the IL so that we can do a better job analyzing and
optimizing.
It may be marginally quicker to be able to launch threads that
execute the same body of code because it avoids the argument
passing overhead for shared stuff and the memory indirection in
the launched functions. But mostly, I'm interested in the IL
elements for optimization and analysis. Launching multiple
threads on the same function body may give us more headaches than
it's worth ATM.
Essentially, we will have an IL expression for every OpenMP
pragma. These expressions are GENERIC and the gimplifier work is
mostly in the bodies. With few exceptions, the controlling
predicates and clauses are required to be in more or less GIMPLE
form by the standard already.
The lowering will, for now, just create a new function and
replace the block of code along the lines of tree-nested.c.
However, in the future, the parallel sections will be
single-entry single-exit regions in the CFG with the controlling
GOMP_PARALLEL_... expression as the entry block and a latch-like
exit block. The parallel region building can be modeled after
the loop structure, but there isn't as much nesting, so it
shouldn't be too complex. As an aside, we do need CFG region
building and the ability to have the optimizers work on
sub-regions (currently being worked on, as I understand).
In fact, even if we don't end up launching threads on the same
function body, we can keep the parallel region inside the
function throughout the optimizers and outline it at a later
point (before RTL, perhaps).
Some runtime library calls (synchronization mostly), ought to be
recognizable as such by the optimizers. I am not sure whether to
define them as builtins, provide an attribute or make them IL
expressions. Any suggestions/ideas?
The IL constructs mostly mirror their #pragma counterparts. Take
these as a design draft, I have only started working on the
implementation, so I expect the design to evolve as I implement
things. There may also be several hidden assumptions that I
expect to become embarrassingly obvious in a few weeks. Names
prefixed with "g_" below mean "the gimplified form of ...".
Parallel regions
----------------
#pragma omp parallel [clause1 ... clauseN]
------------------------------------------
GENERIC
GOMP_PARALLEL <parallel_clauses data_clauses, body>
GIMPLE
GOMP_PARALLEL <g_parallel_clauses g_data_clauses, L1, L2>
L1:
g_body
L2:
#pragma omp for [clause1 ... clauseN]
-------------------------------------
GENERIC
GOMP_FOR <for_clauses data_clauses nowait_clause, init-expr, incr-expr, body>
GIMPLE
GOMP_FOR <g_for_clauses g_data_clauses nowait_clause, init-expr, incr-expr, L1, L2>
L1:
g_body
L2:
Both INIT-EXPR and INCR-EXPR are required to be in GIMPLE
form by the standard already, so there's little that need
to be done there. Keeping them in the header itself
makes it easy to reference later when we're generating
code.
#pragma omp sections [clause1 ... clauseN]
------------------------------------------
GENERIC
GOMP_SECTIONS <data_clauses nowait_clause, body>
GIMPLE
GOMP_SECTIONS <g_data_clauses nowait_clause, L1, L2>
L1:
g_body
L2:
#pragma omp section
-------------------
GENERIC
GOMP_SECTION <body>
GIMPLE
GOMP_SECTION <L1, L2>
L1:
g_body
L2:
#pragma omp single [clause1 ... clauseN]
----------------------------------------
GENERIC
GOMP_SINGLE <data_clauses nowait_clause, body>
GIMPLE
GOMP_SINGLE <g_data_clauses nowait_clause, L1, L2>
L1:
g_body
L2:
#pragma omp master
------------------
GENERIC
GOMP_MASTER <body>
GIMPLE
GOMP_MASTER <L1, L2>
L1:
g_body
L2:
#pragma omp critical [name]
---------------------------
GENERIC
GOMP_CRITICAL <name, block>
GIMPLE
GOMP_CRITICAL <name, L1, L2>
L1:
g_body
L2:
Here, NAME is something the runtime needs to recognize. It will
essentially be the name of the lock to use when emitting the
appropriate lock call.
#pragma omp barrier
-------------------
GENERIC
GIMPLE
GOMP_BARRIER
#pragma omp atomic
-------------------
GENERIC
GIMPLE
GOMP_ATOMIC <expression-statement>
The standard is sufficiently strict that we don't need additional
gimplification here. EXPRESSION-STATEMENT can only be of the form
'VAR binop= EXPR', where EXPR must be of scalar type. ATM, it's not
absolutely clear to me if EXPR needs to be a GIMPLE RHS already or
if it could be more complex. It certainly can't reference VAR.
#pragma omp flush (var-list)
----------------------------
GENERIC
GIMPLE
GOMP_FLUSH <var-list>
#pragma omp ordered
-------------------
GENERIC
GOMP_ORDERED <body>
GIMPLE
GOMP_ORDERED <L1, L2>
L1:
g_body
L2:
#pragma omp threadprivate
-------------------------
This will just set an attribute in each affected _DECL.
Accessible with GOMP_THREADPRIVATE.
for_clauses
-----------
* CLAUSE ordered
GENERIC A boolean field in GOMP_FOR. Accessible with
GOMP_ORDERED.
GIMPLE Same.
* CLAUSE schedule (kind, expr)
GENERIC A structure inside GOMP_FOR. Accessible with
GOMP_SCHEDULE:
enum schedule_kind {
GOMP_SCHED_STATIC,
GOMP_SCHED_DYNAMIC,
GOMP_SCHED_GUIDED,
GOMP_SCHED_RUNTIME } kind;
tree expr;
GIMPLE Same, with EXPR in GIMPLE form as per FE rules.
If missing, it defaults to INTEGER_ONE_NODE for
GOMP_SCHED_DYNAMIC and GOMP_SCHED_GUIDED. It
defaults to iteration-space / num-threads for
GOMP_SCHED_STATIC and it emits getenv reads from
environment for GOM_SCHED_RUNTIME.
nowait_clause
-------------
* CLAUSE nowait
GENERIC A boolean field in GOMP_FOR. Accessible with
GOMP_NOWAIT.
GIMPLE Same.
parallel_clauses
----------------
* CLAUSE if (expr)
GENERIC GOMP_IF <expr>
GIMPLE if (g_expr) goto L1; else goto L2;
L1:
GOMP_PARALLEL <g_parallel_clauses, L2, L3>
L2:
g_body
L3:
* CLAUSE num_threads (expr)
GENERIC A tree field in the GOMP_PARALLEL expression
accessed with GOMP_NUM_THREADS.
GIMPLE Same, with EXPR gimplified as per FE rules.
data_clauses
------------
* CLAUSE private (variable_list)
copyprivate (variable_list)
firstprivate (variable_list)
lastprivate (variable_list)
shared (variable_list)
copyin (variable_list)
GENERIC These are fields in the GOMP_PARALLEL expression.
Accessed with:
GOMP_PRIVATE
GOMP_FIRSTPRIVATE
GOMP_SHARED
GOMP_COPYIN
GIMPLE Same, with variable_list gimplified as per FE
rules.
* CLAUSE default (shared | none)
GENERIC This is a boolean field in the GOMP_PARALLEL
expression.
GIMPLE Same.
* CLAUSE reduction (operator : variable_list)
GENERIC A structure inside GOMP_PARALLEL with two fields
enum tree_code operator -> PLUS_EXPR,
MULT_EXPR,
MINUS_EXPR,
BIT_AND_EXPR,
BIT_XOR_EXPR,
BIT_IOR_EXPR,
AND_EXPR,
OR_EXPR
tree variable_list
GIMPLE Same, with variable_list gimplified as per FE
rules.
Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 20:43 [gomp] OpenMP IL design notes Diego Novillo
@ 2005-05-03 21:05 ` Lars Segerlund
2005-05-03 21:17 ` Diego Novillo
2005-05-03 21:16 ` Richard Henderson
` (2 subsequent siblings)
3 siblings, 1 reply; 18+ messages in thread
From: Lars Segerlund @ 2005-05-03 21:05 UTC (permalink / raw)
To: gcc
Okie,
I will try to look it over, right now I am very busy, and I don't know when I can
get back.
I have to remarks so far, the first is that we have to extend the gfortran internal
representation also, and the second is that perhaps we don't have to have a 1 to 1
mapping of OMP to IL, ( thins of variables and such, I might be wrong but I think
we perhaps can do the same thing a bit easier ).
/ regards, Lars Segerlund.
On Tue, 3 May 2005 16:42:47 -0400
Diego Novillo <dnovillo@redhat.com> wrote:
> I have started working on connecting Dmitry's OpenMP parser to
> the middle-end so that we can start generating the basic runtime
> calls, which Richard should be posting soon. With any luck, we
> should have some basic functionality in a few weeks.
>
> Initially, we will be outlining parallel sections into their own
> functions. This is mostly for implementation convenience.
> However, long term we are better off incorporating parallel
> markers into the IL so that we can do a better job analyzing and
> optimizing.
>
> It may be marginally quicker to be able to launch threads that
> execute the same body of code because it avoids the argument
> passing overhead for shared stuff and the memory indirection in
> the launched functions. But mostly, I'm interested in the IL
> elements for optimization and analysis. Launching multiple
> threads on the same function body may give us more headaches than
> it's worth ATM.
>
> Essentially, we will have an IL expression for every OpenMP
> pragma. These expressions are GENERIC and the gimplifier work is
> mostly in the bodies. With few exceptions, the controlling
> predicates and clauses are required to be in more or less GIMPLE
> form by the standard already.
>
> The lowering will, for now, just create a new function and
> replace the block of code along the lines of tree-nested.c.
> However, in the future, the parallel sections will be
> single-entry single-exit regions in the CFG with the controlling
> GOMP_PARALLEL_... expression as the entry block and a latch-like
> exit block. The parallel region building can be modeled after
> the loop structure, but there isn't as much nesting, so it
> shouldn't be too complex. As an aside, we do need CFG region
> building and the ability to have the optimizers work on
> sub-regions (currently being worked on, as I understand).
>
> In fact, even if we don't end up launching threads on the same
> function body, we can keep the parallel region inside the
> function throughout the optimizers and outline it at a later
> point (before RTL, perhaps).
>
> Some runtime library calls (synchronization mostly), ought to be
> recognizable as such by the optimizers. I am not sure whether to
> define them as builtins, provide an attribute or make them IL
> expressions. Any suggestions/ideas?
>
> The IL constructs mostly mirror their #pragma counterparts. Take
> these as a design draft, I have only started working on the
> implementation, so I expect the design to evolve as I implement
> things. There may also be several hidden assumptions that I
> expect to become embarrassingly obvious in a few weeks. Names
> prefixed with "g_" below mean "the gimplified form of ...".
>
>
> Parallel regions
> ----------------
>
> #pragma omp parallel [clause1 ... clauseN]
> ------------------------------------------
>
> GENERIC
> GOMP_PARALLEL <parallel_clauses data_clauses, body>
>
> GIMPLE
> GOMP_PARALLEL <g_parallel_clauses g_data_clauses, L1, L2>
> L1:
> g_body
> L2:
>
>
> #pragma omp for [clause1 ... clauseN]
> -------------------------------------
>
> GENERIC
> GOMP_FOR <for_clauses data_clauses nowait_clause, init-expr, incr-expr, body>
>
> GIMPLE
> GOMP_FOR <g_for_clauses g_data_clauses nowait_clause, init-expr, incr-expr, L1, L2>
> L1:
> g_body
> L2:
>
> Both INIT-EXPR and INCR-EXPR are required to be in GIMPLE
> form by the standard already, so there's little that need
> to be done there. Keeping them in the header itself
> makes it easy to reference later when we're generating
> code.
>
>
> #pragma omp sections [clause1 ... clauseN]
> ------------------------------------------
>
> GENERIC
> GOMP_SECTIONS <data_clauses nowait_clause, body>
>
> GIMPLE
> GOMP_SECTIONS <g_data_clauses nowait_clause, L1, L2>
> L1:
> g_body
> L2:
>
>
>
> #pragma omp section
> -------------------
>
> GENERIC
> GOMP_SECTION <body>
>
> GIMPLE
> GOMP_SECTION <L1, L2>
> L1:
> g_body
> L2:
>
>
>
> #pragma omp single [clause1 ... clauseN]
> ----------------------------------------
>
> GENERIC
> GOMP_SINGLE <data_clauses nowait_clause, body>
>
> GIMPLE
> GOMP_SINGLE <g_data_clauses nowait_clause, L1, L2>
> L1:
> g_body
> L2:
>
>
>
> #pragma omp master
> ------------------
>
> GENERIC
> GOMP_MASTER <body>
>
> GIMPLE
> GOMP_MASTER <L1, L2>
> L1:
> g_body
> L2:
>
>
> #pragma omp critical [name]
> ---------------------------
>
> GENERIC
> GOMP_CRITICAL <name, block>
>
> GIMPLE
> GOMP_CRITICAL <name, L1, L2>
> L1:
> g_body
> L2:
>
> Here, NAME is something the runtime needs to recognize. It will
> essentially be the name of the lock to use when emitting the
> appropriate lock call.
>
>
> #pragma omp barrier
> -------------------
>
> GENERIC
> GIMPLE
> GOMP_BARRIER
>
>
> #pragma omp atomic
> -------------------
>
> GENERIC
> GIMPLE
> GOMP_ATOMIC <expression-statement>
>
> The standard is sufficiently strict that we don't need additional
> gimplification here. EXPRESSION-STATEMENT can only be of the form
> 'VAR binop= EXPR', where EXPR must be of scalar type. ATM, it's not
> absolutely clear to me if EXPR needs to be a GIMPLE RHS already or
> if it could be more complex. It certainly can't reference VAR.
>
>
> #pragma omp flush (var-list)
> ----------------------------
>
> GENERIC
> GIMPLE
> GOMP_FLUSH <var-list>
>
>
> #pragma omp ordered
> -------------------
>
> GENERIC
> GOMP_ORDERED <body>
>
> GIMPLE
> GOMP_ORDERED <L1, L2>
> L1:
> g_body
> L2:
>
>
> #pragma omp threadprivate
> -------------------------
>
> This will just set an attribute in each affected _DECL.
> Accessible with GOMP_THREADPRIVATE.
>
>
>
> for_clauses
> -----------
>
> * CLAUSE ordered
>
> GENERIC A boolean field in GOMP_FOR. Accessible with
> GOMP_ORDERED.
>
> GIMPLE Same.
>
>
> * CLAUSE schedule (kind, expr)
>
> GENERIC A structure inside GOMP_FOR. Accessible with
> GOMP_SCHEDULE:
>
> enum schedule_kind {
> GOMP_SCHED_STATIC,
> GOMP_SCHED_DYNAMIC,
> GOMP_SCHED_GUIDED,
> GOMP_SCHED_RUNTIME } kind;
>
> tree expr;
>
>
> GIMPLE Same, with EXPR in GIMPLE form as per FE rules.
> If missing, it defaults to INTEGER_ONE_NODE for
> GOMP_SCHED_DYNAMIC and GOMP_SCHED_GUIDED. It
> defaults to iteration-space / num-threads for
> GOMP_SCHED_STATIC and it emits getenv reads from
> environment for GOM_SCHED_RUNTIME.
>
>
>
> nowait_clause
> -------------
>
> * CLAUSE nowait
>
> GENERIC A boolean field in GOMP_FOR. Accessible with
> GOMP_NOWAIT.
>
> GIMPLE Same.
>
>
>
> parallel_clauses
> ----------------
>
> * CLAUSE if (expr)
>
> GENERIC GOMP_IF <expr>
>
> GIMPLE if (g_expr) goto L1; else goto L2;
> L1:
> GOMP_PARALLEL <g_parallel_clauses, L2, L3>
> L2:
> g_body
> L3:
>
>
>
> * CLAUSE num_threads (expr)
>
> GENERIC A tree field in the GOMP_PARALLEL expression
> accessed with GOMP_NUM_THREADS.
>
> GIMPLE Same, with EXPR gimplified as per FE rules.
>
>
>
>
>
> data_clauses
> ------------
>
> * CLAUSE private (variable_list)
> copyprivate (variable_list)
> firstprivate (variable_list)
> lastprivate (variable_list)
> shared (variable_list)
> copyin (variable_list)
>
> GENERIC These are fields in the GOMP_PARALLEL expression.
> Accessed with:
>
> GOMP_PRIVATE
> GOMP_FIRSTPRIVATE
> GOMP_SHARED
> GOMP_COPYIN
>
> GIMPLE Same, with variable_list gimplified as per FE
> rules.
>
>
>
> * CLAUSE default (shared | none)
>
> GENERIC This is a boolean field in the GOMP_PARALLEL
> expression.
>
> GIMPLE Same.
>
>
>
> * CLAUSE reduction (operator : variable_list)
>
> GENERIC A structure inside GOMP_PARALLEL with two fields
>
> enum tree_code operator -> PLUS_EXPR,
> MULT_EXPR,
> MINUS_EXPR,
> BIT_AND_EXPR,
> BIT_XOR_EXPR,
> BIT_IOR_EXPR,
> AND_EXPR,
> OR_EXPR
> tree variable_list
>
> GIMPLE Same, with variable_list gimplified as per FE
> rules.
>
>
>
> Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 20:43 [gomp] OpenMP IL design notes Diego Novillo
2005-05-03 21:05 ` Lars Segerlund
@ 2005-05-03 21:16 ` Richard Henderson
2005-05-03 21:27 ` Diego Novillo
2005-05-04 0:24 ` Ian Lance Taylor
2005-05-05 6:57 ` Dmitry Kurochkin
3 siblings, 1 reply; 18+ messages in thread
From: Richard Henderson @ 2005-05-03 21:16 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc
On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> GENERIC
> GIMPLE
> GOMP_ATOMIC <expression-statement>
Do we gain anything over expanding this to the approprate __sync_foo
builtin in the front end.?
> GENERIC
> GIMPLE
> GOMP_FLUSH <var-list>
Likewise.
> #pragma omp threadprivate
> -------------------------
>
> This will just set an attribute in each affected _DECL.
> Accessible with GOMP_THREADPRIVATE.
My intention is to use TLS for this, and to NOT support this feature
on any system that doesn't support TLS. Thus this bit is synonymous
with DECL_THREAD_LOCAL.
> GIMPLE Same, with EXPR in GIMPLE form as per FE rules.
> If missing, it defaults to INTEGER_ONE_NODE for
> GOMP_SCHED_DYNAMIC and GOMP_SCHED_GUIDED. It
> defaults to iteration-space / num-threads for
> GOMP_SCHED_STATIC and it emits getenv reads from
> environment for GOM_SCHED_RUNTIME.
The getenv is done in the library. You can leave the kind field
NULL, or set it to INTEGER_ZERO_NODE as you choose for the tree
level.
> data_clauses
> ------------
>
> * CLAUSE private (variable_list)
> copyprivate (variable_list)
> firstprivate (variable_list)
> lastprivate (variable_list)
> shared (variable_list)
> copyin (variable_list)
>
> GENERIC These are fields in the GOMP_PARALLEL expression.
> Accessed with:
>
> GOMP_PRIVATE
> GOMP_FIRSTPRIVATE
> GOMP_SHARED
> GOMP_COPYIN
>
> GIMPLE Same, with variable_list gimplified as per FE
> rules.
These shouldn't need gimplification. We should only have decls in
this list.
> * CLAUSE default (shared | none)
>
> GENERIC This is a boolean field in the GOMP_PARALLEL
> expression.
>
> GIMPLE Same.
IMO this shouldn't escape the front end. We have different requirements
for Fortran and C. We should require that front ends do all symbol
resolution and provide GENERIC with a complete list of decls. What
reaches GENERIC should be equivalent to default(none) -- that is, all
variables are either (1) declared inside BIND_EXPRs inside the body of
the block, or (2) mentioned in one of the relevant variable lists.
> * CLAUSE reduction (operator : variable_list)
>
> GENERIC A structure inside GOMP_PARALLEL with two fields
>
> enum tree_code operator -> PLUS_EXPR,
> MULT_EXPR,
> MINUS_EXPR,
> BIT_AND_EXPR,
> BIT_XOR_EXPR,
> BIT_IOR_EXPR,
> AND_EXPR,
> OR_EXPR
> tree variable_list
>
> GIMPLE Same, with variable_list gimplified as per FE
> rules.
This isn't generic enough. The reduction clause can be specified multiple
times. Thus we can see
#pragma omp for reduction(+: a, b) reduction(*: c, d)
I assume the best option would be a list or vector of operator/variable
pairs.
Also note that reduction is also legal on for constructs, and that the
firstprivate, lastprivate, and copyprivate clauses are legal on other
work sharing constructs.
r~
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 21:05 ` Lars Segerlund
@ 2005-05-03 21:17 ` Diego Novillo
2005-05-04 12:20 ` Biagio Lucini
0 siblings, 1 reply; 18+ messages in thread
From: Diego Novillo @ 2005-05-03 21:17 UTC (permalink / raw)
To: Lars Segerlund; +Cc: gcc
On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> I will try to look it over, right now I am very busy, and I
> don't know when I can get back. I have to remarks so far, the
> first is that we have to extend the gfortran internal
> representation also, and the second is that perhaps we don't
>
Yes, initially most of the effort will be in C/C++ since that's
the only parser we have so far.
> have to have a 1 to 1 mapping of OMP to IL, ( thins of
> variables and such, I might be wrong but I think we perhaps
> can do the same thing a bit easier ).
>
Hmm? I'm not quite following you here.
Thanks. Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 21:16 ` Richard Henderson
@ 2005-05-03 21:27 ` Diego Novillo
2005-05-03 22:59 ` Richard Henderson
0 siblings, 1 reply; 18+ messages in thread
From: Diego Novillo @ 2005-05-03 21:27 UTC (permalink / raw)
To: Richard Henderson, gcc
On Tue, May 03, 2005 at 02:16:35PM -0700, Richard Henderson wrote:
> On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> > GENERIC
> > GIMPLE
> > GOMP_ATOMIC <expression-statement>
>
> Do we gain anything over expanding this to the approprate __sync_foo
> builtin in the front end.?
>
Can the optimizers tell that this is an atomic builtin? If so,
then no, they're not necessary.
> My intention is to use TLS for this, and to NOT support this feature
> on any system that doesn't support TLS. Thus this bit is synonymous
> with DECL_THREAD_LOCAL.
>
OK, good.
> These shouldn't need gimplification. We should only have decls in
> this list.
>
That's what I thought at first, but the standard threw me into a
loop when it mentioned "id-expression" instead of just
"identifier" in the C++ case. If they're essentially the same,
then great.
> > * CLAUSE default (shared | none)
> >
> > GENERIC This is a boolean field in the GOMP_PARALLEL
> > expression.
> >
> > GIMPLE Same.
>
> IMO this shouldn't escape the front end. We have different requirements
> for Fortran and C. We should require that front ends do all symbol
> resolution and provide GENERIC with a complete list of decls. What
> reaches GENERIC should be equivalent to default(none) -- that is, all
> variables are either (1) declared inside BIND_EXPRs inside the body of
> the block, or (2) mentioned in one of the relevant variable lists.
>
OK, that's certainly simpler.
> #pragma omp for reduction(+: a, b) reduction(*: c, d)
>
> I assume the best option would be a list or vector of operator/variable
> pairs.
>
Yes. I was only referring to a single instance of reduction.
We'd have to have a vector of those.
> Also note that reduction is also legal on for constructs, and that the
> firstprivate, lastprivate, and copyprivate clauses are legal on other
> work sharing constructs.
>
Yes, I tried to express that by putting common clauses in
data_clauses and have the various constructs reference it.
Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 21:27 ` Diego Novillo
@ 2005-05-03 22:59 ` Richard Henderson
2005-05-04 0:38 ` Diego Novillo
0 siblings, 1 reply; 18+ messages in thread
From: Richard Henderson @ 2005-05-03 22:59 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc
On Tue, May 03, 2005 at 05:27:26PM -0400, Diego Novillo wrote:
> > Do we gain anything over expanding this to the approprate __sync_foo
> > builtin in the front end.?
> >
> Can the optimizers tell that this is an atomic builtin? If so,
> then no, they're not necessary.
Sure, in the same way we know what "strlen" is.
> That's what I thought at first, but the standard threw me into a
> loop when it mentioned "id-expression" instead of just
> "identifier" in the C++ case. If they're essentially the same,
> then great.
id-expression is a non-terminal from the iso c++ grammar. ;-)
It means someone can write e.g. Class::static_member. As far
as you are concerned it means DECL.
> Yes. I was only referring to a single instance of reduction.
...
> Yes, I tried to express that by putting common clauses in
> data_clauses and have the various constructs reference it.
Ah, you confused me.
r~
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 20:43 [gomp] OpenMP IL design notes Diego Novillo
2005-05-03 21:05 ` Lars Segerlund
2005-05-03 21:16 ` Richard Henderson
@ 2005-05-04 0:24 ` Ian Lance Taylor
2005-05-04 0:37 ` Diego Novillo
2005-05-05 6:57 ` Dmitry Kurochkin
3 siblings, 1 reply; 18+ messages in thread
From: Ian Lance Taylor @ 2005-05-04 0:24 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc
Diego Novillo <dnovillo@redhat.com> writes:
> GENERIC
> GOMP_PARALLEL <parallel_clauses data_clauses, body>
>
> GIMPLE
> GOMP_PARALLEL <g_parallel_clauses g_data_clauses, L1, L2>
> L1:
> g_body
> L2:
I personally find it kind of baffling to have the same tree code act
differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
confusion for minimal benefit. If you are suggesting that the single
tree code GOMP_PARALLEL have different operands in GENERIC and GIMPLE,
can I suggest that you instead use two different tree coes?
Ian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 0:24 ` Ian Lance Taylor
@ 2005-05-04 0:37 ` Diego Novillo
2005-05-04 0:48 ` Ian Lance Taylor
0 siblings, 1 reply; 18+ messages in thread
From: Diego Novillo @ 2005-05-04 0:37 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
On Tue, May 03, 2005 at 08:23:59PM -0400, Ian Lance Taylor wrote:
> Diego Novillo <dnovillo@redhat.com> writes:
>
> > GENERIC
> > GOMP_PARALLEL <parallel_clauses data_clauses, body>
> >
> > GIMPLE
> > GOMP_PARALLEL <g_parallel_clauses g_data_clauses, L1, L2>
> > L1:
> > g_body
> > L2:
>
> I personally find it kind of baffling to have the same tree code act
> differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
> confusion for minimal benefit. If you are suggesting that the single
> tree code GOMP_PARALLEL have different operands in GENERIC and GIMPLE,
> can I suggest that you instead use two different tree coes?
>
That is a fundamental feature of both GENERIC and GIMPLE. GIMPLE
is a non-strict subset of GENERIC. Every program in GIMPLE form
is also in GENERIC form. The reverse, however, is not true.
If we did that we would need different codes for every tree code
(MODIFY_EXPR, PLUS_EXPR, etc). Similarly, we would need
different codes when we move from High-GIMPLE into Low-GIMPLE.
I'm not sure that's worth the effort. From the point of view of
analysis and optimizations the differences between the different
ILs are mostly in the grammar, not their syntax.
We could perhaps incorporate tokens to tell which IL we are
dealing with. Currently, that is not really necessary because
the IL is given implicitly by the phase of compilation that you
are in. In the future, we may need to make the distinction if we
become capable of starting the compilation process from an
arbitrary IL dump file.
Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 22:59 ` Richard Henderson
@ 2005-05-04 0:38 ` Diego Novillo
0 siblings, 0 replies; 18+ messages in thread
From: Diego Novillo @ 2005-05-04 0:38 UTC (permalink / raw)
To: Richard Henderson, gcc
On Tue, May 03, 2005 at 03:59:24PM -0700, Richard Henderson wrote:
> Sure, in the same way we know what "strlen" is.
>
Excellent. I'll get rid of them then.
> > That's what I thought at first, but the standard threw me into a
> > loop when it mentioned "id-expression" instead of just
> > "identifier" in the C++ case. If they're essentially the same,
> > then great.
>
> id-expression is a non-terminal from the iso c++ grammar. ;-)
>
Ah, OK. Standardese puts me to sleep in no time ;)
Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 0:37 ` Diego Novillo
@ 2005-05-04 0:48 ` Ian Lance Taylor
2005-05-04 1:18 ` Diego Novillo
0 siblings, 1 reply; 18+ messages in thread
From: Ian Lance Taylor @ 2005-05-04 0:48 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc
Diego Novillo <dnovillo@redhat.com> writes:
> > I personally find it kind of baffling to have the same tree code act
> > differently in GENERIC and GIMPLE, a la SWITCH_EXPR. It seems to add
> > confusion for minimal benefit. If you are suggesting that the single
> > tree code GOMP_PARALLEL have different operands in GENERIC and GIMPLE,
> > can I suggest that you instead use two different tree coes?
> >
> That is a fundamental feature of both GENERIC and GIMPLE. GIMPLE
> is a non-strict subset of GENERIC. Every program in GIMPLE form
> is also in GENERIC form. The reverse, however, is not true.
Well, sure.
But it seems to me that there is a difference. PLUS_EXPR always takes
two operands and adds them together. Given a PLUS_EXPR, you always
where to find the operands, and more or less what they mean. I don't
find that confusing, although I agree that the operands themselves may
be different in GENERIC and GIMPLE.
SWITCH_EXPR is different. Sometimes you use SWITCH_BODY, and
sometimes you use SWITCH_LABELS. How do you know which one to use?
It depends on whether you have GENERIC or GIMPLE.
In particular, this matters for functions like block_may_fallthru,
which are called with both GENERIC and GIMPLE.
> If we did that we would need different codes for every tree code
> (MODIFY_EXPR, PLUS_EXPR, etc). Similarly, we would need
> different codes when we move from High-GIMPLE into Low-GIMPLE.
> I'm not sure that's worth the effort. From the point of view of
> analysis and optimizations the differences between the different
> ILs are mostly in the grammar, not their syntax.
If I understand what you are saying, I am complaining about the
specific cases where the difference is in the syntax. If a tree takes
a different set of operands in GENERIC and GIMPLE, or if the operands
have significantly different meanings, then I think we should use a
different tree code. If the operands are more or less the same, then
I think using the same tree code is fine.
This is obviously all just my opinion, as somebody who came late to
this stuff and is trying to understand it.
Ian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 0:48 ` Ian Lance Taylor
@ 2005-05-04 1:18 ` Diego Novillo
0 siblings, 0 replies; 18+ messages in thread
From: Diego Novillo @ 2005-05-04 1:18 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc
On Tue, May 03, 2005 at 08:48:20PM -0400, Ian Lance Taylor wrote:
> If I understand what you are saying, I am complaining about the
> specific cases where the difference is in the syntax.
>
Drat, trapped in my own web of logic and definitions ;) Yes,
that's exactly what I was saying and now I see the inconsistency
you were pointing out.
Hmm, I'm not quite sure how to go about this. There is another
case where we make these magic passes, COND_EXPR. In GENERIC
each arm is a BIND_EXPR, in GIMPLE each arm is just a label. I
was essentially trying to pull the same stunt.
I kind of like the idea of taking an operand code and twist its
operands slightly when we lower the IL. But then, I'm not the
kind of person you'd want in a language standards committee.
So, there would be 2 such inconsistencies with our current IL
levels: SWITCH_EXPR and COND_EXPR. What would you change?
Perhaps it could be a nice cleanup of the abstraction.
Regarding the GOMP_* codes, perhaps it would suffice to do:
GENERIC GOMP_PARALLEL <clauses, body>
GIMPLE GOMP_PARALLEL <g_clauses, GOTO_EXPR L1>
L1:
g_body
(we can then either put a GOMP_PARALLEL_END marker, or just
figure out the region using std region building techniques).
Notice that we will be very tempted to change that 'GOTO_EXPR L1'
to just 'L1'. No point emitting the GOTO_EXPR when we "know"
that is always a GOTO_EXPR in GIMPLE. That's what led to the
COND_EXPR current structure.
> This is obviously all just my opinion, as somebody who came late to
> this stuff and is trying to understand it.
>
Which is exactly the kind of POV that can usually spot
inconsistencies such as this one :)
Thanks. Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 21:17 ` Diego Novillo
@ 2005-05-04 12:20 ` Biagio Lucini
2005-05-04 13:00 ` Diego Novillo
2005-05-04 13:42 ` Paul Brook
0 siblings, 2 replies; 18+ messages in thread
From: Biagio Lucini @ 2005-05-04 12:20 UTC (permalink / raw)
To: Lars Segerlund; +Cc: Diego Novillo, gcc
On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
>
> On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
>
> > we have to extend the gfortran internal representation also
>
> Yes, initially most of the effort will be in C/C++ since that's
> the only parser we have so far.
>
Is there any obstruction in principle to have the so-called sentinel directive
(!$OMP) recognised by the gfortran parser? Talking with Lars, I have
understood that at the moment some misbehaviour of the front-end prevents it,
but I don't quite understand what the problem is. Can anyone shed some light?
Also, talking about IR, since OpenMP is mostly unique, probably we just need
to link the gfortran parser to the work in the middle-end that is currently
being done, with perhaps a few (hopefully no) exception.
Biagio
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 12:20 ` Biagio Lucini
@ 2005-05-04 13:00 ` Diego Novillo
2005-05-04 13:42 ` Paul Brook
1 sibling, 0 replies; 18+ messages in thread
From: Diego Novillo @ 2005-05-04 13:00 UTC (permalink / raw)
To: Biagio Lucini; +Cc: Lars Segerlund, gcc
On Wed, May 04, 2005 at 12:15:18PM +0000, Biagio Lucini wrote:
> Also, talking about IR, since OpenMP is mostly unique, probably
> we just need to link the gfortran parser to the work in the
> middle-end that is currently being done, with perhaps a few
> (hopefully no) exception.
>
Yes, the FEs emit GENERIC. Lowering and code generation is all
common code. Some constructs like workshare will only be
generated by Fortran, but that will also be handled by common
code.
Diego.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 12:20 ` Biagio Lucini
2005-05-04 13:00 ` Diego Novillo
@ 2005-05-04 13:42 ` Paul Brook
2005-05-04 15:50 ` Biagio Lucini
1 sibling, 1 reply; 18+ messages in thread
From: Paul Brook @ 2005-05-04 13:42 UTC (permalink / raw)
To: gcc; +Cc: Biagio Lucini, Lars Segerlund, Diego Novillo
On Wednesday 04 May 2005 13:15, Biagio Lucini wrote:
> On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
> > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> > > we have to extend the gfortran internal representation also
> >
> > Yes, initially most of the effort will be in C/C++ since that's
> > the only parser we have so far.
>
> Is there any obstruction in principle to have the so-called sentinel
> directive (!$OMP) recognised by the gfortran parser?
I have no objections. It'd be nice to have OpenMP support, but it's not
currently a high priority for me.
> Talking with Lars, I
> have understood that at the moment some misbehaviour of the front-end
> prevents it, but I don't quite understand what the problem is. Can anyone
> shed some light?
Basically the fortran parser does trial-and-error pattern matching, and can
end up parsing a single comment many times.
Paul
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 13:42 ` Paul Brook
@ 2005-05-04 15:50 ` Biagio Lucini
2005-05-04 15:52 ` Steven Bosscher
2005-05-04 15:56 ` Paul Brook
0 siblings, 2 replies; 18+ messages in thread
From: Biagio Lucini @ 2005-05-04 15:50 UTC (permalink / raw)
To: gcc; +Cc: Paul Brook, Lars Segerlund, Diego Novillo
On Wednesday 04 May 2005 13.34, Paul Brook wrote:
>
> On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
>
> > I have understood that at the moment some misbehaviour of the front-end
> > prevents it, but I don't quite understand what the problem is. Can anyone
> > shed some light?
>
> Basically the fortran parser does trial-and-error pattern matching, and can
> end up parsing a single comment many times.
>
Is this a permanent feature or something that can be removed? The reason why I
am asking is that I would like to experiment with this front-end a little
bit.
Thanks
Biagio
--
=========================================================
Biagio Lucini
Institut Fuer Theoretische Physik
ETH Hoenggerberg
CH-8093 Zuerich - Switzerland
Tel. +41 (0)1 6332562
=========================================================
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 15:50 ` Biagio Lucini
@ 2005-05-04 15:52 ` Steven Bosscher
2005-05-04 15:56 ` Paul Brook
1 sibling, 0 replies; 18+ messages in thread
From: Steven Bosscher @ 2005-05-04 15:52 UTC (permalink / raw)
To: gcc; +Cc: Biagio Lucini, Paul Brook, Lars Segerlund, Diego Novillo
On Wednesday 04 May 2005 17:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what the problem
> > > is. Can anyone shed some light?
> >
> > Basically the fortran parser does trial-and-error pattern matching, and
> > can end up parsing a single comment many times.
>
> Is this a permanent feature or something that can be removed? The reason
> why I am asking is that I would like to experiment with this front-end a
> little bit.
You could rewrite the parser... ;-)
Gr.
Steven
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-04 15:50 ` Biagio Lucini
2005-05-04 15:52 ` Steven Bosscher
@ 2005-05-04 15:56 ` Paul Brook
1 sibling, 0 replies; 18+ messages in thread
From: Paul Brook @ 2005-05-04 15:56 UTC (permalink / raw)
To: Biagio Lucini; +Cc: gcc, Lars Segerlund, Diego Novillo
On Wednesday 04 May 2005 16:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what the problem
> > > is. Can anyone shed some light?
> >
> > Basically the fortran parser does trial-and-error pattern matching, and
> > can end up parsing a single comment many times.
>
> Is this a permanent feature or something that can be removed? The reason
> why I am asking is that I would like to experiment with this front-end a
> little bit.
It's more of an implementation wart than a feature.
I don't think anyone's particularly attached to our current parser. If it
needs significant changes to support OpenMP then I've no real objections, as
long as it still works :-)
Paul
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [gomp] OpenMP IL design notes
2005-05-03 20:43 [gomp] OpenMP IL design notes Diego Novillo
` (2 preceding siblings ...)
2005-05-04 0:24 ` Ian Lance Taylor
@ 2005-05-05 6:57 ` Dmitry Kurochkin
3 siblings, 0 replies; 18+ messages in thread
From: Dmitry Kurochkin @ 2005-05-05 6:57 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc
Hi.
Looks good to me.
Also I hope to post new pragma handling mechanism patch in near
future. Currently I'm trying to find sparc/solaris box to make some
tests. This will require some minor changes to the parser. In
particular I plan to remove threadprivate handler from FE to a
separate handler which just sets TLS flag.
--
Dmitry
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2005-05-05 6:51 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-03 20:43 [gomp] OpenMP IL design notes Diego Novillo
2005-05-03 21:05 ` Lars Segerlund
2005-05-03 21:17 ` Diego Novillo
2005-05-04 12:20 ` Biagio Lucini
2005-05-04 13:00 ` Diego Novillo
2005-05-04 13:42 ` Paul Brook
2005-05-04 15:50 ` Biagio Lucini
2005-05-04 15:52 ` Steven Bosscher
2005-05-04 15:56 ` Paul Brook
2005-05-03 21:16 ` Richard Henderson
2005-05-03 21:27 ` Diego Novillo
2005-05-03 22:59 ` Richard Henderson
2005-05-04 0:38 ` Diego Novillo
2005-05-04 0:24 ` Ian Lance Taylor
2005-05-04 0:37 ` Diego Novillo
2005-05-04 0:48 ` Ian Lance Taylor
2005-05-04 1:18 ` Diego Novillo
2005-05-05 6:57 ` Dmitry Kurochkin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).