On Sun, Jul 26, 2015 at 4:21 PM, Tom de Vries wrote:
> I wrote an equivalent test-case in C:
> ...
> $ cat src/gcc/testsuite/gcc.dg/autopar/outer-7.c
> /* { dg-do compile } */
> /* { dg-options "-O2 -ftree-parallelize-loops=2 -fdump-tree-parloops-details
> -fdump-tree-optimized" } */
>
> void abor
On 16/07/15 12:28, Richard Biener wrote:
On Thu, Jul 16, 2015 at 12:23 PM, Richard Biener
wrote:
On Thu, Jul 16, 2015 at 12:19 PM, Thomas Schwinge
wrote:
Hi Tom!
On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener
wrote:
On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries wrote:
I tried to pa
On Wed, Jul 22, 2015 at 1:01 PM, Richard Biener
wrote:
> On Tue, Jul 21, 2015 at 8:42 PM, Sebastian Pop wrote:
>> Tom de Vries wrote:
>>> Fix reduction safety checks
>>>
>>> * graphite-sese-to-poly.c (is_reduction_operation_p): Limit
>>> flag_associative_math to SCALAR_FLOAT_TYPE_P.
On Tue, Jul 21, 2015 at 8:42 PM, Sebastian Pop wrote:
> Tom de Vries wrote:
>> Fix reduction safety checks
>>
>> * graphite-sese-to-poly.c (is_reduction_operation_p): Limit
>> flag_associative_math to SCALAR_FLOAT_TYPE_P. Honour
>> TYPE_OVERFLOW_TRAPS and TYPE_OVERFLOW_WRAPS for
Tom de Vries wrote:
> Fix reduction safety checks
>
> * graphite-sese-to-poly.c (is_reduction_operation_p): Limit
> flag_associative_math to SCALAR_FLOAT_TYPE_P. Honour
> TYPE_OVERFLOW_TRAPS and TYPE_OVERFLOW_WRAPS for INTEGRAL_TYPE_P.
> Only allow wrapping fixed-point oth
On 21/07/15 02:21, Tom de Vries wrote:
On 20/07/15 20:31, Sebastian Pop wrote:
Tom de Vries wrote:
So I wondered, why not always use the graphite dependency analysis
in parloops. (Of course you could use -floop-parallelize-all, but
that also changes the heuristic). So I wrote a patch for parloo
On 20/07/15 20:31, Sebastian Pop wrote:
Tom de Vries wrote:
So I wondered, why not always use the graphite dependency analysis
in parloops. (Of course you could use -floop-parallelize-all, but
that also changes the heuristic). So I wrote a patch for parloops to
use graphite dependency analysis b
On 20/07/15 20:22, Sebastian Pop wrote:
Tom de Vries wrote:
graphite dependence analysis is too slow to be enabled unconditionally.
(read: hours in some simple cases - see bugzilla)
Haha, "cool"! ;-)
Maybe it is still reasonable to use graphite to analyze the code inside
OpenACC kernels regi
Tom de Vries wrote:
> So I wondered, why not always use the graphite dependency analysis
> in parloops. (Of course you could use -floop-parallelize-all, but
> that also changes the heuristic). So I wrote a patch for parloops to
> use graphite dependency analysis by default (so without
> -floop-para
Tom de Vries wrote:
> >>>graphite dependence analysis is too slow to be enabled unconditionally.
> >>>(read: hours in some simple cases - see bugzilla)
> >>
> >>Haha, "cool"! ;-)
> >>
> >>Maybe it is still reasonable to use graphite to analyze the code inside
> >>OpenACC kernels regions -- maybe s
On 16/07/15 12:23, Richard Biener wrote:
On Thu, Jul 16, 2015 at 12:19 PM, Thomas Schwinge
wrote:
Hi Tom!
On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener
wrote:
On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries wrote:
I tried to parallelize this fortran test-case (based on autopar/outer-1
On Thu, Jul 16, 2015 at 12:23 PM, Richard Biener
wrote:
> On Thu, Jul 16, 2015 at 12:19 PM, Thomas Schwinge
> wrote:
>> Hi Tom!
>>
>> On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener
>> wrote:
>>> On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries
>>> wrote:
>>> > I tried to parallelize this fo
On Thu, Jul 16, 2015 at 12:19 PM, Thomas Schwinge
wrote:
> Hi Tom!
>
> On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener
> wrote:
>> On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries
>> wrote:
>> > I tried to parallelize this fortran test-case (based on autopar/outer-1.c),
>> > [...]
>
>> > So I
Hi Tom!
On Thu, 16 Jul 2015 10:46:00 +0200, Richard Biener
wrote:
> On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries wrote:
> > I tried to parallelize this fortran test-case (based on autopar/outer-1.c),
> > [...]
> > So I wondered, why not always use the graphite dependency analysis in
> > parl
On Wed, Jul 15, 2015 at 10:26 PM, Tom de Vries wrote:
> Hi,
>
> I tried to parallelize this fortran test-case (based on autopar/outer-1.c),
> specifically the outer loop of the first loop nest using
> -ftree-parallelize-loops=2:
> ...
> program main
> implicit none
> integer, parameter
Hi,
I tried to parallelize this fortran test-case (based on
autopar/outer-1.c), specifically the outer loop of the first loop nest
using -ftree-parallelize-loops=2:
...
program main
implicit none
integer, parameter :: n = 500
integer, dimension (0:n-1, 0:n-1) :: x
integer
16 matches
Mail list logo
