On Wed, 28 Feb 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcases are miscompiled, because graphite ignores boolean,
> enumerated or _BitInt comparisons, rewrites the code as if the comparisons
> were always true or always false.
>
> The INTEGER_TYPE checks were initially added in r6-2
Hi!
The following testcases are miscompiled, because graphite ignores boolean,
enumerated or _BitInt comparisons, rewrites the code as if the comparisons
were always true or always false.
The INTEGER_TYPE checks were initially added in r6-2239 but at that point
it was both in add_conditions_to_do
On 12/19/2017 02:05 PM, Richard Biener wrote:
On Tue, 19 Dec 2017, Tom de Vries wrote:
On 09/21/2017 12:07 PM, Richard Biener wrote:
-exit_edge = create_empty_if_region_on_edge (entry_edge,
- unshare_expr (cond_expr));
This removes the fix fo
On Tue, 19 Dec 2017, Tom de Vries wrote:
> On 09/21/2017 12:07 PM, Richard Biener wrote:
> > -exit_edge = create_empty_if_region_on_edge (entry_edge,
> > - unshare_expr (cond_expr));
>
> This removes the fix for PR70045:
> ...
> diff --git a/gcc/graph
On 09/21/2017 12:07 PM, Richard Biener wrote:
-exit_edge = create_empty_if_region_on_edge (entry_edge,
- unshare_expr (cond_expr));
This removes the fix for PR70045:
...
diff --git a/gcc/graphite-isl-ast-to-gimple.c
b/gcc/graphite-isl-ast-to-gi
On Sun, Oct 01, 2017 at 11:58:30AM +0200, Sven Verdoolaege wrote:
> For the approach pluto is taking, you'll have to look at the source
> code, see pluto_intra_tile_optimize_band.
> For the other two approaches I mentioned above, reports will
> be made available within the next couple of weeks.
ht
This tames dumping a bit and adjusts whitespacing and order of dumping.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-20 Richard Biener
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::graphite_copy_stmts_from_block):
Remove
The following limits ISL operations done during optimized AST generation
as the PR shows it can take quite a bit of time.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-18 Richard Biener
PR tree-optimization/82591
* graphite.c (graphite_transf
And using range-info to constain parameters.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-18 Richard Biener
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::set_rename): Simplify.
(translate_isl_ast_to_gimple::set_rename_
The isl_union_map operations always take the existing map and return
a new one but scop_get_reads_and_writes tries to operate on its
parameters in-place. This fails once a re-allocation happens leading
to "interesting" issues (like random segfaults with
-fdump-tree-graphite-details on larger tes
The following removes copy_internal_parameters and the parameter rename
map. It got dead by myself forgetting to copy the member to the
false if-region part ... and in previous mail we discussed we'd rather
wait for a testcase showing the need to handle "parameters" defined in
the region.
Bootst
PR82573 shows the ugly part of an earlier fix, that we now split the
entry edge of SCOPs during analysis phase to get a GBB for the entry
edge PHI copies. That invalidates loop-closed SSA in some cases like
the PR. So the following patch gets rid of that "fake" GBB by explicitely
emitting SESE e
On Sat, 14 Oct 2017, Sebastian Pop wrote:
> On Fri, Oct 13, 2017 at 8:02 AM, Richard Biener wrote:
>
> >
> > Now that SCEV instantiation handles regions properly (see hunk below
> > for a minor fix) we can use it consistently from GRAPHITE and thus
> > simplify scalar_evolution_in_region greatly
On Fri, Oct 13, 2017 at 8:02 AM, Richard Biener wrote:
>
> Now that SCEV instantiation handles regions properly (see hunk below
> for a minor fix) we can use it consistently from GRAPHITE and thus
> simplify scalar_evolution_in_region greatly.
>
> Bootstrap and regtest running on x86_64-unknown-l
Now that SCEV instantiation handles regions properly (see hunk below
for a minor fix) we can use it consistently from GRAPHITE and thus
simplify scalar_evolution_in_region greatly.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
A lot of the parameter renaming stuff looks dead but a m
This is something I wanted to do later just as compile-time optimization
but it turns out it is necessary for correctness if we want to keep
the current order of creating SCOPs and analyzing data references and
parameters and only after that code-generating SCOPs that were optimized.
This is beca
Removing a global constructor, a return value that isn't checked
and adjusting testcases that spew -Waggressive-loop-optimization
warnings when built with different options.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-10-13 Richard Biener
* graphite-i
On Oct 12, 2017 4:36 AM, "Richard Biener" wrote:
The following avoids code-generation errors for modulo operations
resulting from our own constraints ending up as no-ops because
the type we code-generate in already imposes the modulo operation.
For the case in SPEC 2k6 triggering this we'd even
On Oct 12, 2017 9:08 AM, "Richard Biener" wrote:
I made scheduling to fail when we end up with an empty domain but as
I forgot to actually check the return value of build_original_schedule
the fix was equivalent to just doing nothing to the schedule when
it has an empty domain. I verified that
On Oct 12, 2017 9:29 AM, "Richard Biener" wrote:
The type check seems premature (we're checking CHRECs already) and
we certainly can handle POINTER IVs just fine.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
SPEC CPU 2k6 sees ~100 more loop nest optimizations that way.
Ok?
[I'd r
On Oct 11, 2017 9:43 AM, "Richard Biener" wrote:
For PR82355 I introduced a fake dimension to ISL to allow CHRECs
having an evolution in a loop that isn't fully part of the SESE
region we are processing. That was easier than fending off those
CHRECs (without simply giving up on SESE regions wit
The type check seems premature (we're checking CHRECs already) and
we certainly can handle POINTER IVs just fine.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
SPEC CPU 2k6 sees ~100 more loop nest optimizations that way.
Ok?
[I'd rather have problematical testcases for those weird
I made scheduling to fail when we end up with an empty domain but as
I forgot to actually check the return value of build_original_schedule
the fix was equivalent to just doing nothing to the schedule when
it has an empty domain. I verified that for the testcase it DCEs
the relevant stmt and that
On Thu, Oct 12, 2017 at 12:13 PM, Richard Biener wrote:
> On Thu, 12 Oct 2017, Bin.Cheng wrote:
>
>> On Wed, Oct 11, 2017 at 3:43 PM, Richard Biener wrote:
>> >
>> > For PR82355 I introduced a fake dimension to ISL to allow CHRECs
>> > having an evolution in a loop that isn't fully part of the SE
On Thu, 12 Oct 2017, Bin.Cheng wrote:
> On Wed, Oct 11, 2017 at 3:43 PM, Richard Biener wrote:
> >
> > For PR82355 I introduced a fake dimension to ISL to allow CHRECs
> > having an evolution in a loop that isn't fully part of the SESE
> > region we are processing. That was easier than fending o
On Wed, Oct 11, 2017 at 3:43 PM, Richard Biener wrote:
>
> For PR82355 I introduced a fake dimension to ISL to allow CHRECs
> having an evolution in a loop that isn't fully part of the SESE
> region we are processing. That was easier than fending off those
> CHRECs (without simply giving up on SE
The following avoids code-generation errors for modulo operations
resulting from our own constraints ending up as no-ops because
the type we code-generate in already imposes the modulo operation.
For the case in SPEC 2k6 triggering this we'd even know the
modulo constraint isn't necessary - we h
For PR82355 I introduced a fake dimension to ISL to allow CHRECs
having an evolution in a loop that isn't fully part of the SESE
region we are processing. That was easier than fending off those
CHRECs (without simply giving up on SESE regions with those).
But it didn't fully solve the issue as P
On Oct 9, 2017 8:48 AM, "Richard Biener" wrote:
On Mon, 9 Oct 2017, Richard Biener wrote:
> On Fri, 6 Oct 2017, Sebastian Pop wrote:
>
> > On Fri, Oct 6, 2017 at 8:33 AM, Richard Biener
wrote:
> >
> > > On Fri, 6 Oct 2017, Sebastian Pop wrote:
> > >
> > > > On Fri, Oct 6, 2017 at 6:56 AM, Richa
On Mon, 9 Oct 2017, Richard Biener wrote:
> On Fri, 6 Oct 2017, Sebastian Pop wrote:
>
> > On Fri, Oct 6, 2017 at 8:33 AM, Richard Biener wrote:
> >
> > > On Fri, 6 Oct 2017, Sebastian Pop wrote:
> > >
> > > > On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener
> > > wrote:
> > > >
> > > > >
> > >
On Fri, 6 Oct 2017, Sebastian Pop wrote:
> On Fri, Oct 6, 2017 at 8:33 AM, Richard Biener wrote:
>
> > On Fri, 6 Oct 2017, Sebastian Pop wrote:
> >
> > > On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener
> > wrote:
> > >
> > > >
> > > > The following fences off a few more SCEVs through scev_analyz
On Fri, Oct 6, 2017 at 8:33 AM, Richard Biener wrote:
> On Fri, 6 Oct 2017, Sebastian Pop wrote:
>
> > On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener
> wrote:
> >
> > >
> > > The following fences off a few more SCEVs through scev_analyzable_p
> given
> > > at the end we need those pass chrec_app
On Fri, 6 Oct 2017, Sebastian Pop wrote:
> On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener wrote:
>
> >
> > The following fences off a few more SCEVs through scev_analyzable_p given
> > at the end we need those pass chrec_apply when getting a rename through
> > SCEV.
> >
> > The SCEV in question
On Fri, Oct 6, 2017 at 6:56 AM, Richard Biener wrote:
>
> The following fences off a few more SCEVs through scev_analyzable_p given
> at the end we need those pass chrec_apply when getting a rename through
> SCEV.
>
> The SCEV in question is
>
> {(integer(kind=4)) {0, +, {1, +, 1}_1}_1, + 1}_2
On Fri, Oct 6, 2017 at 6:27 AM, Richard Biener
wrote:
>
> > Richard, could you please commit this patch, as I will need to figure out
> > why my
> > ssh keys don't let me to commit the code. I will probably need to update
> > the key.
>
> Done. You probably still have a v1 key which were rejecte
The following fences off a few more SCEVs through scev_analyzable_p given
at the end we need those pass chrec_apply when getting a rename through
SCEV.
The SCEV in question is
{(integer(kind=4)) {0, +, {1, +, 1}_1}_1, + 1}_2
which fails to chrec_apply in the CHREC_LEFT part because that part
On Thu, Oct 5, 2017 at 4:27 PM, Sebastian Pop wrote:
>
>
> On Mon, Oct 2, 2017 at 4:18 AM, Richard Biener
> wrote:
>>
>> On Mon, Oct 2, 2017 at 6:53 AM, Sebastian Pop
>> wrote:
>> > The patch moves the code that translates reads and writes to isl
>> > representation
>> > in a same loop. This is
On Thu, Oct 5, 2017 at 9:20 AM, Sebastian Pop wrote:
>
> We also need to tag commutative and associative reductions
> in the dependence graph. Now that the code generation will
> nicely handle scalar dependences, we may want to add back
> some of the code from this commit:
> https://gcc.gnu.org/v
On Mon, Oct 2, 2017 at 4:18 AM, Richard Biener
wrote:
> On Mon, Oct 2, 2017 at 6:53 AM, Sebastian Pop
> wrote:
> > The patch moves the code that translates reads and writes to isl
> representation
> > in a same loop. This is to avoid traversing the scop blocks and arrays
> with
> > memory opera
On Wed, Oct 4, 2017 at 2:45 AM, Richard Biener wrote:
>
> While my last change involving signed types was correct it wasn't optimal.
> We can avoid the modulo constraints if the conversion is widening
> (thus all values fit in the new type).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu
On Thu, Oct 5, 2017 at 6:43 AM, Richard Biener wrote:
> On Wed, 4 Oct 2017, Richard Biener wrote:
>
> >
> > The following patch completely re-does PHI handling during
> > code-generation. PHI handling is currently responsible for 99% of
> > all code-generation issues. With the patch the number
On Wed, 4 Oct 2017, Richard Biener wrote:
>
> The following patch completely re-does PHI handling during
> code-generation. PHI handling is currently responsible for 99% of
> all code-generation issues. With the patch the number of code-generation
> issues in SPEC 2k6 decreases from 180 to 5,
The following patch completely re-does PHI handling during
code-generation. PHI handling is currently responsible for 99% of
all code-generation issues. With the patch the number of code-generation
issues in SPEC 2k6 decreases from 180 to 5, similar adjustments happen
to the testsuite - only gf
While my last change involving signed types was correct it wasn't optimal.
We can avoid the modulo constraints if the conversion is widening
(thus all values fit in the new type).
Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?
Thanks,
Richard.
2017-10-04 Richard Biener
* g
uOn Tue, 3 Oct 2017, Rainer Orth wrote:
> Hi Richard,
>
> > What ISL Versions are affected?
>
> it's 0.18.
>
> >>Besides, there's
> >>
> >>+UNRESOLVED: gfortran.dg/graphite/pr42393-1.f90 -O
> >>scan-tree-dump-times graphite "code generation error" 1
> >>
> >>for both 32 and 64-bit. The lo
Hi Richard,
> What ISL Versions are affected?
it's 0.18.
>>Besides, there's
>>
>>+UNRESOLVED: gfortran.dg/graphite/pr42393-1.f90 -O
>>scan-tree-dump-times graphite "code generation error" 1
>>
>>for both 32 and 64-bit. The log indicates
>>
>>gfortran.dg/graphite/pr42393-1.f90 -O : dump
On October 3, 2017 11:48:35 AM GMT+02:00, Rainer Orth
wrote:
>Hi Richard,
>
>> The following patch adjust GRAPHITE testing to check that existing
>> code generation issues occur and makes code generation ICE with
>> -fchecking --param graphite-allow-codegen-errors=0. The param
>> is really a tes
Hi Richard,
> The following patch adjust GRAPHITE testing to check that existing
> code generation issues occur and makes code generation ICE with
> -fchecking --param graphite-allow-codegen-errors=0. The param
> is really a testsuite artifact so we can have testcases with
> issues where we have
On Mon, Oct 2, 2017 at 4:58 AM, Richard Biener wrote:
>
> The following patch adjust GRAPHITE testing to check that existing
> code generation issues occur and makes code generation ICE with
> -fchecking --param graphite-allow-codegen-errors=0. The param
> is really a testsuite artifact so we can
The following patch adjust GRAPHITE testing to check that existing
code generation issues occur and makes code generation ICE with
-fchecking --param graphite-allow-codegen-errors=0. The param
is really a testsuite artifact so we can have testcases with
issues where we have papered over GRAPHITE
On Mon, Oct 2, 2017 at 6:53 AM, Sebastian Pop wrote:
> The patch moves the code that translates reads and writes to isl
> representation
> in a same loop. This is to avoid traversing the scop blocks and arrays with
> memory operations 3 times.
LGTM.
Richard.
> * graphite-dependences.c
The patch moves the code that translates reads and writes to isl representation
in a same loop. This is to avoid traversing the scop blocks and arrays with
memory operations 3 times.
* graphite-dependences.c (scop_get_reads): Move code to...
(scop_get_must_writes): Move code to...
On Sat, Sep 30, 2017 at 07:47:43PM +0200, Richard Biener wrote:
> On September 29, 2017 9:58:41 PM GMT+02:00, Sebastian Pop
> wrote:
> >On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
> > wrote:
> >> [Sorry for the resend; I used the wrong email address to CC Alex]
> >>
> >> On Wed, Sep 27, 201
On September 29, 2017 9:58:41 PM GMT+02:00, Sebastian Pop
wrote:
>On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
> wrote:
>> [Sorry for the resend; I used the wrong email address to CC Alex]
>>
>> On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
>>> Ah, so I now see why we do no
On 29/09/17 21:58, Sebastian Pop wrote:
On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
wrote:
[Sorry for the resend; I used the wrong email address to CC Alex]
On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
Ah, so I now see why we do not perform interchange on trivial ca
On Fri, Sep 29, 2017 at 2:37 PM, Sven Verdoolaege
wrote:
> [Sorry for the resend; I used the wrong email address to CC Alex]
>
> On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
>> Ah, so I now see why we do not perform interchange on trivial cases like
>>
>> double A[1024][1024], B
[Sorry for the resend; I used the wrong email address to CC Alex]
On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
> Ah, so I now see why we do not perform interchange on trivial cases like
>
> double A[1024][1024], B[1024][1024];
>
> void foo(void)
> {
> for (int i = 0; i < 102
On Wed, Sep 27, 2017 at 02:18:51PM +0200, Richard Biener wrote:
> Ah, so I now see why we do not perform interchange on trivial cases like
>
> double A[1024][1024], B[1024][1024];
>
> void foo(void)
> {
> for (int i = 0; i < 1024; ++i)
> for (int j = 0; j < 1024; ++j)
> A[j][i] = B[j]
On Fri, Sep 29, 2017 at 6:17 AM, Richard Biener wrote:
> I fixed the "hack patch" somewhat but realized it's not really possible
> ATM to get back at this form because the array descriptor contains only
> information to generate the linearized form. So while I get now correct
> values they end up
On Fri, Sep 29, 2017 at 3:52 AM, Richard Biener wrote:
>
> This moves it to a function to make it easy to enable ICEin on them
> in one place.
>
> Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2017-09-29 Richard Biener
>
> * graphite-isl-ast-to-gimple.c
>
On Fri, Sep 29, 2017 at 6:18 AM, Richard Biener wrote:
> The idea is that we'd transform the above to
> basically wrap each SCOP inside a loop that doesn't iterate.
>
> Does this look reasonable?
Yes, I think your solution looks good.
> 2017-09-29 Richard Biener
>
> PR tree-optimizati
On Fri, 29 Sep 2017, Richard Biener wrote:
>
> For gcc.dg/graphite/scop-4.c when we analyze data-refs of the fist
> two inner loops (with the scalar BB in between)
>
> for (i = 1; i < 100; i++) /// loop 1
> {
> -- scop start
> for (j = 1; j < 80; j++) /// loop 2
> a[j][i] =
For gcc.dg/graphite/scop-4.c when we analyze data-refs of the fist
two inner loops (with the scalar BB in between)
for (i = 1; i < 100; i++) /// loop 1
{
-- scop start
for (j = 1; j < 80; j++) /// loop 2
a[j][i] = a[j+1][2*i-1*j] + 12;
b[i] = b[i-1] + 10;
for (j
On Thu, 28 Sep 2017, Sebastian Pop wrote:
> On Wed, Sep 27, 2017 at 9:33 AM, Richard Biener wrote:
> > Looks like even when hacking the Fortran FE to produce nested
> > ARRAY_REFs we run into the same issue for
> >
> > (gdb) p debug_data_reference (dr)
> > #(Data Ref:
> > # bb: 17
> > # stmt:
>
On Thu, 28 Sep 2017, Sebastian Pop wrote:
> On Wed, Sep 27, 2017 at 6:51 AM, Richard Biener wrote:
> >
> > The following is to allow making --param graphite-max-arrays-per-scop
> > unbounded. That's a little tricky because the bound is used when
> > computing "alias-sets" for scalar constraints.
This moves it to a function to make it easy to enable ICEin on them
in one place.
Bootstrapped / tested on x86_64-unknown-linux-gnu, applied.
Richard.
2017-09-29 Richard Biener
* graphite-isl-ast-to-gimple.c
(translate_isl_ast_to_gimple::set_codegen_error): New function.
On Wed, Sep 27, 2017 at 7:20 AM, Richard Biener wrote:
>
> Currently ISL aborts on this special value and for debugging (and
> tuning?) it's nice to avoid all the clutter introduced by tiling.
>
> Committed as obvious.
>
> Richard.
>
> 2017-09-27 Richard Biener
>
> * graphite-optimize-i
On Wed, Sep 27, 2017 at 6:51 AM, Richard Biener wrote:
>
> The following is to allow making --param graphite-max-arrays-per-scop
> unbounded. That's a little tricky because the bound is used when
> computing "alias-sets" for scalar constraints. There's an easy way
> out though as we know the max
On Wed, Sep 27, 2017 at 6:48 AM, Richard Biener wrote:
>
> Turns out loop_nest recorded in scop-info isn't really necessary as
> we can simply process parameters in loop bounds during the gather_bbs
> walk where we encounter each loop (identified by its header) once.
>
> This avoids the linear sea
On Wed, Sep 27, 2017 at 6:07 AM, Richard Biener wrote:
> /* Maximal number of array references in a scop. */
>
DEFPARAM (PARAM_GRAPHITE_MAX_ARRAYS_PER_SCOP,
"graphite-max-arrays-per-scop",
"maximum number of arrays per scop.",
100, 0, 0)
Let's also remove this para
On Wed, Sep 27, 2017 at 6:07 AM, Richard Biener wrote:
>
> This removes another quadraticness from SCOP detection, gather_bbs
> domwalk. This is done by enhancing domwalk to handle SEME regions
> via a special return value from before_dom_children.
>
> With this I'm now confident to remove the
>
On Wed, Sep 27, 2017 at 2:21 AM, Richard Biener wrote:
> On Tue, 26 Sep 2017, Sebastian Pop wrote:
>
>> On Tue, Sep 26, 2017 at 7:03 AM, Richard Biener wrote:
>>
>> >
>> > The following is the result of me trying to understand SCOP detection
>> > and the validity checks spread around the machiner
On Wed, Sep 27, 2017 at 9:33 AM, Richard Biener wrote:
> Looks like even when hacking the Fortran FE to produce nested
> ARRAY_REFs we run into the same issue for
>
> (gdb) p debug_data_reference (dr)
> #(Data Ref:
> # bb: 17
> # stmt:
> VIEW_CONVERT_EXPR(*y_117(D))[_24]{lb:
> 1 sz: _20 * 8}[_26
On Wed, Sep 27, 2017 at 8:04 AM, Richard Biener wrote:
>
> Another thing I notice is that we don't handle the multi-dimensional
> accesses the fortran frontend produces:
>
> (gdb) p debug_data_reference (dr)
> #(Data Ref:
> # bb: 18
> # stmt: _43 = *a_141(D)[_42];
> # ref: *a_141(D)[_42];
> #
On Wed, Sep 27, 2017 at 7:18 AM, Richard Biener wrote:
> On Tue, 26 Sep 2017, Sebastian Pop wrote:
>
> > On Mon, Sep 25, 2017 at 8:12 AM, Richard Biener
> wrote:
> >
> > > On Fri, 22 Sep 2017, Sebastian Pop wrote:
> > >
> > > > On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener
> > > wrote:
> > >
Hi skimo,
On Tue, Sep 26, 2017 at 10:15 AM, Sven Verdoolaege <
sven.verdoola...@gmail.com> wrote:
> On Tue, Sep 26, 2017 at 09:19:50AM -0500, Sebastian Pop wrote:
> > Sven, is there already a function that computes the sum of all
> > strides in a proximity map? Maybe you have code that does
> >
On Wed, 27 Sep 2017, Richard Biener wrote:
> On Wed, 27 Sep 2017, Richard Biener wrote:
>
> > On Tue, 26 Sep 2017, Sebastian Pop wrote:
> >
> > > On Mon, Sep 25, 2017 at 8:12 AM, Richard Biener wrote:
> > >
> > > > On Fri, 22 Sep 2017, Sebastian Pop wrote:
> > > >
> > > > > On Fri, Sep 22, 201
On Wed, 27 Sep 2017, Richard Biener wrote:
> On Tue, 26 Sep 2017, Sebastian Pop wrote:
>
> > On Mon, Sep 25, 2017 at 8:12 AM, Richard Biener wrote:
> >
> > > On Fri, 22 Sep 2017, Sebastian Pop wrote:
> > >
> > > > On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener
> > > wrote:
> > > >
> > > > >
>
Currently ISL aborts on this special value and for debugging (and
tuning?) it's nice to avoid all the clutter introduced by tiling.
Committed as obvious.
Richard.
2017-09-27 Richard Biener
* graphite-optimize-isl.c (get_schedule_for_node_st): Allow
--param loop-block-tile-s
On Tue, 26 Sep 2017, Sebastian Pop wrote:
> On Mon, Sep 25, 2017 at 8:12 AM, Richard Biener wrote:
>
> > On Fri, 22 Sep 2017, Sebastian Pop wrote:
> >
> > > On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener
> > wrote:
> > >
> > > >
> > > > This simplifies canonicalize_loop_closed_ssa and does oth
The following is to allow making --param graphite-max-arrays-per-scop
unbounded. That's a little tricky because the bound is used when
computing "alias-sets" for scalar constraints. There's an easy way
out though as we know the maximum alias-set assigned in the SCOP,
we only have to remember it.
Turns out loop_nest recorded in scop-info isn't really necessary as
we can simply process parameters in loop bounds during the gather_bbs
walk where we encounter each loop (identified by its header) once.
This avoids the linear search in record_loop_in_sese.
Bootstrap / regtest running on x86_64
This removes another quadraticness from SCOP detection, gather_bbs
domwalk. This is done by enhancing domwalk to handle SEME regions
via a special return value from before_dom_children.
With this I'm now confident to remove the
PARAM_GRAPHITE_MAX_BBS_PER_FUNCTION parameter and its associated li
On Tue, 26 Sep 2017, Sebastian Pop wrote:
> On Tue, Sep 26, 2017 at 7:03 AM, Richard Biener wrote:
>
> >
> > The following is the result of me trying to understand SCOP detection
> > and the validity checks spread around the machinery. It removes several
> > quadraticnesses by folding validity
On Tue, Sep 26, 2017 at 09:19:50AM -0500, Sebastian Pop wrote:
> Sven, is there already a function that computes the sum of all
> strides in a proximity map? Maybe you have code that does
> something similar in pet or ppcg?
What exactly do you want to sum?
If this involves any counting, then it c
On Tue, Sep 26, 2017 at 7:03 AM, Richard Biener wrote:
>
> The following is the result of me trying to understand SCOP detection
> and the validity checks spread around the machinery. It removes several
> quadraticnesses by folding validity checks into
> scop_detection::harmful_loop_in_region wh
On Mon, Sep 25, 2017 at 8:12 AM, Richard Biener wrote:
> On Fri, 22 Sep 2017, Sebastian Pop wrote:
>
> > On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener
> wrote:
> >
> > >
> > > This simplifies canonicalize_loop_closed_ssa and does other minimal
> > > TLC. It also adds a testcase I reduced from
On Mon, Sep 25, 2017 at 4:47 AM, Richard Biener wrote:
>
> The following also dumps if the optimized schedule is equal to the
> original one. It also makes all ISL operations (well, nearly) not
> abort on errors but instead propagate errors upward.
>
> Bootstrapped and tested on x86_64-unknown-l
The following is the result of me trying to understand SCOP detection
and the validity checks spread around the machinery. It removes several
quadraticnesses by folding validity checks into
scop_detection::harmful_loop_in_region where we already walk over all
BBs in the region and process indivi
On Fri, 22 Sep 2017, Sebastian Pop wrote:
> On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener wrote:
>
> >
> > This simplifies canonicalize_loop_closed_ssa and does other minimal
> > TLC. It also adds a testcase I reduced from a stupid mistake I made
> > when reworking canonicalize_loop_closed_ss
On Mon, 25 Sep 2017, Bin.Cheng wrote:
> On Mon, Sep 25, 2017 at 1:46 PM, Richard Biener wrote:
> > On Mon, 25 Sep 2017, Richard Biener wrote:
> >
> >> On Fri, 22 Sep 2017, Richard Biener wrote:
> >>
> >> >
> >> > This simplifies canonicalize_loop_closed_ssa and does other minimal
> >> > TLC. It
On Mon, Sep 25, 2017 at 1:46 PM, Richard Biener wrote:
> On Mon, 25 Sep 2017, Richard Biener wrote:
>
>> On Fri, 22 Sep 2017, Richard Biener wrote:
>>
>> >
>> > This simplifies canonicalize_loop_closed_ssa and does other minimal
>> > TLC. It also adds a testcase I reduced from a stupid mistake I
On Mon, 25 Sep 2017, Richard Biener wrote:
> On Fri, 22 Sep 2017, Richard Biener wrote:
>
> >
> > This simplifies canonicalize_loop_closed_ssa and does other minimal
> > TLC. It also adds a testcase I reduced from a stupid mistake I made
> > when reworking canonicalize_loop_closed_ssa.
> >
> >
The following also dumps if the optimized schedule is equal to the
original one. It also makes all ISL operations (well, nearly) not
abort on errors but instead propagate errors upward.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2017-09-25 Richard Biener
On Fri, 22 Sep 2017, Richard Biener wrote:
>
> This simplifies canonicalize_loop_closed_ssa and does other minimal
> TLC. It also adds a testcase I reduced from a stupid mistake I made
> when reworking canonicalize_loop_closed_ssa.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applie
On Fri, Sep 22, 2017 at 8:03 AM, Richard Biener wrote:
>
> This simplifies canonicalize_loop_closed_ssa and does other minimal
> TLC. It also adds a testcase I reduced from a stupid mistake I made
> when reworking canonicalize_loop_closed_ssa.
>
> Bootstrapped and tested on x86_64-unknown-linux-
On Fri, Sep 22, 2017 at 4:37 AM, Richard Biener wrote:
>
> This re-implements it avoding the need to recompute dominators and in
> a much simpler way.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, SPEC CPU
> 2006 is happy.
>
> Richard.
>
> 2017-09-22 Richard Biener
>
>
This simplifies canonicalize_loop_closed_ssa and does other minimal
TLC. It also adds a testcase I reduced from a stupid mistake I made
when reworking canonicalize_loop_closed_ssa.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
SPEC CPU 2006 is happy with it, current sta
This re-implements it avoding the need to recompute dominators and in
a much simpler way.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, SPEC CPU
2006 is happy.
Richard.
2017-09-22 Richard Biener
* sese.c: Include cfganal.h.
(if_region_set_false_region): Rem
The following is a quick attempt at reducing pass overhead. The
main part is maintaining post-dominators only during scop detection
and not recomputing / verifying everything many many times for no
good reason.
Somehow this means I ran into a latent bug where ISL split
a loop into two, not mixin
1 - 100 of 202 matches
Mail list logo
