Thomas Koenig wrote:
Regression-tested. OK for trunk (finally)?
Looks also OK from my side - except for the left over which Jakub has
already noticed. I think the following lines can be simply removed:
- case EXEC_OMP_DO:
+ in_omp_workshare = true;
+
+ brea
On Sun, Dec 11, 2011 at 11:11:28AM +0100, Thomas Koenig wrote:
> @@ -1330,16 +1345,38 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code
> WALK_SUBEXPR (co->ext.dt->extra_comma);
> break;
>
> - case EXEC_OMP_DO:
> + in_omp_workshare = true;
> +
> +
Am 08.12.2011 22:57, schrieb Jakub Jelinek:
Reading it again, isn't it overkill to keep the
vector? All you need is a bool and a way to restore its previous state.
Good catch. The vector was a leftover from the time when I was searching
up the call chain to check for any enclosing workshare.
On Thu, Dec 08, 2011 at 08:48:31PM +0100, Thomas Koenig wrote:
> this is what I hope is the final round of the OMP front-end optimization
> patch. This one ignores outer workshares when doing function
> elimination within omp do and similar blocks.
Sorry, stopped reading the patch details once no
On Thu, Dec 08, 2011 at 09:36:13PM +0100, Thomas Koenig wrote:
> >Both of these arrays should be really vec.h vectors, it doesn't
> >make any sense to handcode the same thing everywhere.
> >You can then start with NULL vectors and push something using VEC_safe_push
> >only when needed and let it ha
Hi Jakub,
Both of these arrays should be really vec.h vectors, it doesn't
make any sense to handcode the same thing everywhere.
You can then start with NULL vectors and push something using VEC_safe_push
only when needed and let it handle reallocation etc.
I tried that originally, but could no
On Thu, Dec 08, 2011 at 08:48:31PM +0100, Thomas Koenig wrote:
> /* Entry point - run all passes for a namespace. So far, only an
> optimization pass is run. */
>
> @@ -76,12 +83,15 @@ gfc_run_passes (gfc_namespace *ns)
> {
>expr_size = 20;
>expr_array = XNEWVEC(gfc_ex
Hello world,
this is what I hope is the final round of the OMP front-end optimization
patch. This one ignores outer workshares when doing function
elimination within omp do and similar blocks.
Regression-tested. OK for trunk?
Thomas
2011-12-02 Thomas Koenig
PR fortran/50
Hi Tobias,
I'm just back from holiday, which it took me a bit longer to reply.
Actually, the test case is *not* OK.
If one compiles the original test case of the PR (or your
workshare2.f90) with "-O" and looks at "-fdump-tree-original", one finds:
#pragma omp parallel default(shared)
Tobias Burnus wrote:
I had also a glance at the patch - and it looks reasonable; in
particular, I failed to generate a failing test case.
Actually, the test case is *not* OK.
If one compiles the original test case of the PR (or your
workshare2.f90) with "-O" and looks at "-fdump-tree-original
Mikael Morin wrote:
Let's keep Jakub CC-ed for mixes of OpenMP and frontend optimizations. ;-)
There are two commented lines in the testcase. Is it expected?
Otherwise doesn't look too bad...
I had also a glance at the patch - and it looks reasonable; in
particular, I failed to generate a fai
On Tuesday 25 October 2011 07:39:44 Thomas Koenig wrote:
> Ping ** 0.571428
>
Let's keep Jakub CC-ed for mixes of OpenMP and frontend optimizations. ;-)
There are two commented lines in the testcase. Is it expected?
Otherwise doesn't look too bad...
Mikael
> > Jakub Jelinek wrote:
> >> Though,
Ping ** 0.571428
Jakub Jelinek wrote:
Though, what could be done is just special case OpenMP workshare regions,
insert everything into BLOCK local vars unless in OpenMP workshare, in
that
case put the BLOCK with the temporary around the workshare rather than
inside of it. In the case of omp par
Jakub Jelinek wrote:
Though, what could be done is just special case OpenMP workshare regions,
insert everything into BLOCK local vars unless in OpenMP workshare, in that
case put the BLOCK with the temporary around the workshare rather than
inside of it. In the case of omp parallel workshare it
Hi Tobias,
> I think that's the wrong solution to the problem: I think it makes more
> sense to fix the handling for OMP workshare to handle BLOCK correctly
> rather than to move the variable to the function scope and then to
> fiddle with the private attribute.
What is the reason for that?
I d
On Sat, Oct 15, 2011 at 07:19:43PM +0200, Jakub Jelinek wrote:
> On Sat, Oct 15, 2011 at 06:36:55PM +0200, Tobias Burnus wrote:
> > I think that's the wrong solution to the problem: I think it makes
> > more sense to fix the handling for OMP workshare to handle BLOCK
> > correctly rather than to mo
On Sat, Oct 15, 2011 at 06:36:55PM +0200, Tobias Burnus wrote:
> I think that's the wrong solution to the problem: I think it makes
> more sense to fix the handling for OMP workshare to handle BLOCK
> correctly rather than to move the variable to the function scope and
> then to fiddle with the pri
Am 15.10.2011 14:04, schrieb Thomas Koenig:
Am 15.10.2011 13:36, schrieb Jakub Jelinek:
This looks wrong. Threadprivate variables aren't completely cheap,
much better would be an automatic variable instead.
As Fortran FE IL doesn't have block local variables, I guess you want
to create the var
Hi Jakub,
I guess you want
to create the var at function scope and add a private(that_temporary)
clause to the nearest enclosing OpenMP directive.
Here is a patch which implements this. Regression-tested, no new
failures. OK for trunk?
Thomas
2011-10-15 Thomas Koenig
PR
Am 15.10.2011 13:36, schrieb Jakub Jelinek:
This looks wrong. Threadprivate variables aren't completely cheap,
much better would be an automatic variable instead.
As Fortran FE IL doesn't have block local variables, I guess you want
to create the var at function scope and add a private(that_tem
On Sat, Oct 15, 2011 at 11:02:12AM +0200, Thomas Koenig wrote:
> Hello world,
>
> here is a fix for PR 50690, pretty self-explanatory. Regression-tested.
> OK for trunk?
This looks wrong. Threadprivate variables aren't completely cheap,
much better would be an automatic variable instead.
As For
Hello world,
here is a fix for PR 50690, pretty self-explanatory. Regression-tested.
OK for trunk?
Thomas
2011-10-15 Thomas Koenig
PR fortran/50690
* frontend-passes.c (omp_level): New variable.
(create_var): If we are within an OMP block, put
the
22 matches
Mail list logo
