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
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
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
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
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
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
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,
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
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
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] =
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.
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:
> > > >
> > > > >
>
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
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
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.
> >
> >
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
>
>
On Thu, Sep 21, 2017 at 5:07 AM, Richard Biener wrote:
>
> This PR is about code generation issues with us inserting "loop header
> copies" in the attempt to cover up cases where the loop doesn't run.
> But we are disregarding such cases early already. Thus the simple
> fix is to not emit those
On Thu, Sep 21, 2017 at 4:44 AM, Richard Biener wrote:
>
> The following fixes the IL after code generation errors so we can
> continue processing SCOPs. This increases the number of transformed
> loop nests in SPEC CPU 2006 by 50%.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
On Tue, Sep 19, 2017 at 3:30 AM, Richard Biener wrote:
>
> The following plugs some holes in extract_affine which failed
> to modulo-reduce signed values in conversions, failed to
> interpret pointer-plus offsets as signed (yeah, stupid GIMPLE IL...)
> and mishandled BIT_NOT_EXPR.
>
> Bootstrap a
On Wed, Jun 7, 2017 at 4:46 AM, Richard Biener wrote:
>
> When the order of visiting dominator children in domwalk changed
> GRAPHITE falls foul of relying on a particular order BBs are visited
> when computing the original schedule from the vector of pbbs.
>
> The following restores an order that
On Tue, May 30, 2017 at 7:56 AM, Richard Biener wrote:
>
> We currently ICE when code generating loop-closed PHIs that are after-loop
> used IVs. I didn't manage to find the place during analysis that is
> supposed to reject such SCOPs thus the following patch "simply" makes
> us properly generat
Hi!
On Wed, 15 Feb 2017 13:44:13 +0100, I wrote:
> On Fri, 10 Feb 2017 15:13:57 +0100 (CET), Richard Biener
> wrote:
> > As a cleanup (and to be able to close bugs only reproducing with ISL 0.14)
> > the following removes support for ISL 0.14 for GCC 7.
> OK to commit the following to restore g
On Wed, Feb 15, 2017 at 6:44 AM, Thomas Schwinge
wrote:
> Hi!
>
> On Fri, 10 Feb 2017 15:13:57 +0100 (CET), Richard Biener
> wrote:
>> As a cleanup (and to be able to close bugs only reproducing with ISL 0.14)
>> the following removes support for ISL 0.14 for GCC 7.
>
> (This got committed in r2
On February 15, 2017 1:44:13 PM GMT+01:00, Thomas Schwinge
wrote:
>Hi!
>
>On Fri, 10 Feb 2017 15:13:57 +0100 (CET), Richard Biener
> wrote:
>> As a cleanup (and to be able to close bugs only reproducing with ISL
>0.14)
>> the following removes support for ISL 0.14 for GCC 7.
>
>(This got committe
Hi!
On Fri, 10 Feb 2017 15:13:57 +0100 (CET), Richard Biener
wrote:
> As a cleanup (and to be able to close bugs only reproducing with ISL 0.14)
> the following removes support for ISL 0.14 for GCC 7.
(This got committed in r245382.)
> --- config/isl.m4 (revision 245328)
> +++ config/isl.m
On February 14, 2017 4:50:32 PM GMT+01:00, Sebastian Pop
wrote:
>On Tue, Feb 14, 2017 at 7:09 AM, Richard Biener
>wrote:
>>
>> This removes all GMP code from graphite and instead arranges to use
>> widest_ints plus the generic ISL interface for building/creating vals
>> by pieces. This removes
On 02/11/2017 08:24 AM, Richard Biener wrote:
> On February 11, 2017 12:38:32 AM GMT+01:00, Jakub Jelinek
> wrote:
>> On Fri, Feb 10, 2017 at 04:34:30PM -0700, Jeff Law wrote:
2017-02-10 Richard Biener
config/
* isl.m4: Remove support for ISL 0.14.
* conf
On February 11, 2017 12:38:32 AM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 10, 2017 at 04:34:30PM -0700, Jeff Law wrote:
>> > 2017-02-10 Richard Biener
>> >
>> >config/
>> >* isl.m4: Remove support for ISL 0.14.
>> >
>> >* configure: Re-generate.
>> >
>> >gcc/
>> >* c
On Fri, Feb 10, 2017 at 04:34:30PM -0700, Jeff Law wrote:
> > 2017-02-10 Richard Biener
> >
> > config/
> > * isl.m4: Remove support for ISL 0.14.
> >
> > * configure: Re-generate.
> >
> > gcc/
> > * configure.ac (HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS):
> > Remo
On 02/10/2017 07:13 AM, Richard Biener wrote:
As a cleanup (and to be able to close bugs only reproducing with ISL 0.14)
the following removes support for ISL 0.14 for GCC 7. This removes quite
a bit of legacy code (which would need to be maintained).
Bootstrap / regtest in progress with ISL 0
On Feb 2, 2016, at 10:29 PM, Sebastian Huber
wrote:
> If it is so basic to choose the latest release or the one on the system, then
> why uses the contrib/download_prerequisites ancient versions, e.g. the six
> year old GMP 4.3.2?
Because no one has seen fit to update it? I’ll plead ignorance
On 03/02/16 07:29, Sebastian Huber wrote:
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian
Huber wrote:
>It would be good to have a recommended version as well (similar for
cloog, gmp, mpc and mpfr). If you present me three versions which
one should I choose as a
On 02/02/16 19:00, Mike Stump wrote:
On Feb 2, 2016, at 2:23 AM, Sebastian Huber
wrote:
>It would be good to have a recommended version as well (similar for cloog,
gmp, mpc and mpfr). If you present me three versions which one should I choose as
a naive user?
The latest release, or the on
On Feb 2, 2016, at 2:23 AM, Sebastian Huber
wrote:
> It would be good to have a recommended version as well (similar for cloog,
> gmp, mpc and mpfr). If you present me three versions which one should I
> choose as a naive user?
The latest release, or the one on your system. This is so basic t
On 01/02/16 19:27, Mike Stump wrote:
On Jan 29, 2016, at 8:10 AM, Sebastian Pop wrote:
>diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
>index 062f42c..3df7974 100644
>--- a/gcc/doc/install.texi
>+++ b/gcc/doc/install.texi
>@@ -383,7 +383,7 @@ installed but it is not in your default li
On Jan 29, 2016, at 8:10 AM, Sebastian Pop wrote:
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 062f42c..3df7974 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -383,7 +383,7 @@ installed but it is not in your default library search
> path, the
> @option
On Thu, Jan 28, 2016 at 8:32 AM, Sebastian Pop wrote:
> 2016-01-28 Abderrazek Zaafrani
>
> * graphite-optimize-isl.c (optimize_isl): Print a different debug
> message when isl does not return a valid schedule.
> ---
> gcc/graphite-optimize-isl.c | 11 +--
> 1 file chang
Hi,
This break the build for me, with isl 0.14.
...
src/gcc/graphite-isl-ast-to-gimple.c: In member function ‘tree_node*
translate_isl_ast_to_gimple::binary_op_to_tree(tree, isl_ast_expr*,
ivs_params&)’:
src/gcc/graphite-isl-ast-to-gimple.c:591:10: error: ‘isl_ast_op_zdiv_r’
was not declared
anges.
-Aditya
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Wednesday, October 07, 2015 9:02 AM
To: hiraditya
Cc: GCC Patches; s@samsung.com; Tobias Grosser; aditya...@samsung.com;
Richard Biener
Subject: Re: [PATCH] [graphite] use debug_pr
On Wed, Oct 7, 2015 at 2:55 PM, hiraditya wrote:
> The debug_printer provides an elegant way to represent debug related
> statements, so we are extending its usage throughout graphite infrastructure.
> No functional changes intended. Passes regtest and bootstrap.
But the DEBUG_PRINT macro is supe
On 09/05/2015 12:57 AM, Aditya Kumar wrote:
This patch removes graphite-scop-detection.c:limit_scops function and fix
related issues arising because of that. The functionality limit_scop was added
as an intermediate step to discard the loops which graphite could not
handle. Removing limit_scop re
> Subject: RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> Date: Fri, 14 Aug 2015 16:47:41 +0200
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>
On August 14, 2015 4:31:23 PM GMT+02:00, Aditya K wrote:
>
>
>
>> Date: Fri, 14 Aug 2015 11:47:05 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: hiradi...
> Date: Fri, 14 Aug 2015 11:47:05 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>
On Fri, Aug 14, 2015 at 11:25 AM, Aditya K wrote:
>
>
>
>> Date: Fri, 14 Aug 2015 09:31:32 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: hiradi...@msn.
> Date: Fri, 14 Aug 2015 09:31:32 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>
1 - 100 of 128 matches
Mail list logo
