This avoids segfaulting in the GIMPLE parser on invalid input.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-10-28 Richard Biener
PR c/92249
* gimple-parser.c (c_parser_parse_gimple_body): Make
current_bb the entry block initially to
On Fri, 25 Oct 2019, Richard Biener wrote:
>
> This is a cleanup. The cond-reduction restriction can go,
> the fold-left one stays (it cannot handle more than one stmt in
> the cycle - in the future when we get partial loop vectorization
> generic code would handle duplicating
hard.
2019-10-28 Richard Biener
PR tree-optimization/92241
* tree-vect-loop.c (vect_fixup_scalar_cycles_with_patterns): When
we failed to update the reduction index do not use the pattern
stmts for the reduction chain.
(vectorizable_reduction): When
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
>
>
> On 22/10/2019 14:56, Richard Biener wrote:
> > On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
> >
> >> Hi Richi,
> >>
> >> See inline responses to your comments.
> >>
> >&g
makes sure vectorizable_live_operation
picks it up as reduction. Finally some invariants process_use
checks are no longer true.
Nicely simple ;)
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-10-28 Richard Biener
PR tree-optimization/65930
* tree-
ue_vinfos.
> (vect_do_peeling, vect_update_inits_of_drs,
> determine_peel_for_niter, vect_analyze_loop): Add or update declarations.
> * tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already
> created loop_vec_info's for epilogues when available. Otherwise
> analyse
> epilogue separately.
>
>
>
> Cheers,
> Andre
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Fri, Oct 25, 2019 at 9:58 PM Prathamesh Kulkarni
wrote:
>
> On Fri, 25 Oct 2019 at 13:19, Richard Biener
> wrote:
> >
> > On Wed, Oct 23, 2019 at 11:45 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > Hi,
> > > The attached patch tries to f
On October 28, 2019 6:18:26 PM GMT+01:00, Segher Boessenkool
wrote:
>On Mon, Oct 28, 2019 at 09:08:04AM +0100, Richard Biener wrote:
>> On Fri, 25 Oct 2019, Jiufu Guo wrote:
>> > On powerpc64le, for O2 , enable -funroll-loops and limit
>> > PARAM_MAX_UNROLL_TIMES=2 a
On October 28, 2019 7:43:33 PM GMT+01:00, David Edelsohn
wrote:
>>> Has this been bootstrapped and regression tested?
>>
>> Yes, it bootstraps OK of course. I ran regression over the weekend,
>there
>> are a few minor regressions in lto due to relying on tentative
>definitions
>> and a few latent
Committed.
Richard.
2019-10-29 Richard Biener
PR tree-optimization/92241
* gcc.dg/torture/pr92241-2.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr92241-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr92241
On Mon, Oct 28, 2019 at 10:39 PM Iain Sandoe wrote:
>
> Wilco Dijkstra wrote:
> >>>
> >>> I suppose targets can override this decision.
> >> I think they probably could via the override_options mechanism.
> >
> > Yes, it's trivial to add this to target_option_override():
> >
> > if (!global_opti
; >>
> >>> On Wed, 23 Oct 2019 at 23:07, Richard Biener
> > wrote:
> >>
> >>>> Did you try this with multiple assembler options? I see you stream
> >>>> them as -Wa,-mfpu=xyz,-mthumb but then compare the whole
> >>>>
suite/gcc.target/powerpc/ppc-fma-4.c
> > index c2eaf1a..291c2ee 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/ppc-fma-4.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/ppc-fma-4.c
> > @@ -2,7 +2,7 @@
> > /* { dg-skip-if "" { powerpc*-*-darwin* } } */
> > /* { dg-require-effective-target powerpc_altivec_ok } */
> > /* { dg-require-effective-target powerpc_fprs } */
> > -/* { dg-options "-O3 -ftree-vectorize -mdejagnu-cpu=power6 -maltivec
> > -ffast-math -ffp-contract=off" } */
> > +/* { dg-options "-O3 -ftree-vectorize -mdejagnu-cpu=power6 -maltivec
> > -ffast-math -ffp-contract=off -fno-unroll-loops" } */
> > /* { dg-final { scan-assembler-times "vmaddfp" 1 } } */
> > /* { dg-final { scan-assembler-times "fmadd " 1 } } */
> > /* { dg-final { scan-assembler-times "fmadds" 1 } } */
> > diff --git a/gcc/testsuite/gcc.target/powerpc/pr78604.c
> > b/gcc/testsuite/gcc.target/powerpc/pr78604.c
> > index 76d8945..35bfdb3 100644
> > --- a/gcc/testsuite/gcc.target/powerpc/pr78604.c
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr78604.c
> > @@ -1,7 +1,7 @@
> > /* { dg-do compile { target { powerpc*-*-* } } } */
> > /* { dg-skip-if "" { powerpc*-*-darwin* } } */
> > /* { dg-require-effective-target powerpc_p8vector_ok } */
> > -/* { dg-options "-mdejagnu-cpu=power8 -O2 -ftree-vectorize
> > -fdump-tree-vect-details" } */
> > +/* { dg-options "-mdejagnu-cpu=power8 -O2 -ftree-vectorize
> > -fdump-tree-vect-details -fno-unroll-loops" } */
> >
> > #ifndef SIZE
> > #define SIZE 1024
> > diff --git a/gcc/testsuite/gcc.target/powerpc/small-loop-unroll.c
> > b/gcc/testsuite/gcc.target/powerpc/small-loop-unroll.c
> > new file mode 100644
> > index 000..fec5ae9
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/small-loop-unroll.c
> > @@ -0,0 +1,13 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -fdump-rtl-loop2_unroll" } */
> > +
> > +void __attribute__ ((noinline)) foo(int n, int *arr)
> > +{
> > + int i;
> > + for (i = 0; i < n; i++)
> > +arr[i] = arr[i] - 10;
> > +}
> > +/* { dg-final { scan-rtl-dump-times "Unrolled loop 1 times" 1
> > "loop2_unroll" } } */
> > +/* { dg-final { scan-assembler-times {\mlwz\M} 3 } } */
> > +/* { dg-final { scan-assembler-times {\mstw\M} 3 } } */
> > +
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Tue, 29 Oct 2019, Bernhard Reutner-Fischer wrote:
> On Mon, 28 Oct 2019 14:55:37 +0100 (CET)
> Richard Biener wrote:
>
> > Index: gcc/tree-vect-loop.c
> > ===
> > --- gcc/tree-vect-loop.c(revisi
While I converted other iterators requiring special BREAK_FROM_XYZ
a few years ago FOR_EACH_IMM_USE_STMT is remaining. I've pondered
a bit but cannot arrive at a "nice" solution here with just one
iterator as the macros happen to use. For reference, the macro use is
imm_use_iterator iter;
On Tue, 29 Oct 2019, Richard Sandiford wrote:
> Richard Biener writes:
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
> >
> > Richard.
> >
> > 2019-10-21 Richard Biener
> >
> > PR tree-optimization/92162
> > *
On Tue, 29 Oct 2019, Bernhard Reutner-Fischer wrote:
> On 29 October 2019 10:36:47 CET, Richard Biener wrote:
> >On Tue, 29 Oct 2019, Bernhard Reutner-Fischer wrote:
> >
>
>
> >Unfortunately it's not semantically equivalent ;) I could indeed
> >break o
_inits_of_drs,
> determine_peel_for_niter, vect_analyze_loop): Add or update declarations.
> * tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already
> created loop_vec_info's for epilogues when available. Otherwise
> analyse
> epilogue separately.
determine_peel_for_niter, vect_analyze_loop): Add or update declarations.
> * tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already
> created loop_vec_info's for epilogues when available. Otherwise
> analyse
> epilogue separately.
>
>
>
>
The following fixes the PR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-29 Richard Biener
PR tree-optimization/92260
* tree-vect-slp.c (vect_get_constant_vectors): Special-case
lane-reducing ops.
* gcc.dg/pr92260.c: New
-unknown-linux-gnu, testing in progress.
Richard.
2019-10-29 Richard Biener
PR tree-optimization/65930
* tree-vect-loop.c (vect_is_simple_reduction): For reduction
chains also allow a leading and trailing conversion.
* tree-vect-slp.c (vect_get_and_check_slp_defs
On Tue, Oct 29, 2019 at 8:34 PM Jeff Law wrote:
>
> On 10/29/19 6:26 AM, John Paul Adrian Glaubitz wrote:
> > Hello!
> >
> > We have raised $5000 to support anyone willing to work on this for the
> > m68k target [1]. We really need the m68k to stay as it's essential to
> > be able to compile for L
On Tue, 29 Oct 2019, Oleg Endo wrote:
> On Tue, 2019-10-29 at 11:26 +0100, Richard Biener wrote:
> > While I converted other iterators requiring special BREAK_FROM_XYZ
> > a few years ago FOR_EACH_IMM_USE_STMT is remaining. I've pondered
> > a bit but cannot arrive at a
+ typedef L L;
> +};
> +template
> +template
> +void P::corge (V y)
> +{
> + quux ();
> + for (L x = k.n.j; x < k.o.j; ++x)
> + {
> +++y;
> +D pv;
> +baz (y, *x, pv);
> + }
> + D z;
> + baz (y, k.o.i, z);
> +}
> +struct A {
> + A (int x) : a (x) {}
> + int a;
> +};
> +int a[2]{};
> +
> +int
> +main ()
> +{
> + P (a, a);
> + return 0;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Wed, 30 Oct 2019, Alexandre Oliva wrote:
> On Oct 28, 2019, Richard Biener wrote:
>
> > I guess you need to elaborate on 'per-file'. With LTO as far as I
> > understand you'll get the graph per LTRANS unit (did you check
> > where the output is gener
On Wed, 30 Oct 2019, Joel Hutton wrote:
> On 15/10/2019 13:11, Richard Biener wrote:
> >> > You miss to check that CONSTRUCTOR_NELTS == TYPE_VECTOR_SUBPARTS
> >> > (we can have omitted trailing zeros).
> >
> > ^^^
> >
> > I don'
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-10-30 Richard Biener
PR tree-optimization/92275
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
Copy all loop-closed PHIs.
* gcc.dg/torture/pr92275.c: New testcase
r is large enough. */
> + #pragma GCC unroll 8
>for (i=0;i a->a[i]++;
> }
> diff --git a/gcc/testsuite/gcc.dg/var-expand3.c
> b/gcc/testsuite/gcc.dg/var-expand3.c
> index dce6ec1..d2ca6df 100644
> --- a/gcc/testsuite/gcc.dg/var-expand3.c
> +++ b/gcc/testsuite/gcc.dg/var-expand3.c
> @@ -21,6 +21,8 @@ foo (int n)
>
>vaccum = vzero;
>
> + /* Using pragma unroll to make sure unroll enough times. */
> + #pragma GCC unroll 8
>for (i = 0; i < n; i++)
> {
>vp1 = vec_ld (i * 16, in1);
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Wed, Oct 30, 2019 at 9:50 AM Martin Liška wrote:
>
> Hello.
>
> Have you ever waited for a LTO compilation and were curious about
> the progress? If so, the patch offers a way to communicate that information
> to user via setprocessname. The process will reflect progress of ltrans
> compilation
On Wed, Oct 30, 2019 at 10:30 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR92127 shows, recent commit r276645 enables more unrollings,
> two ppc vectorization cost model test cases are fragile and failed
> after the change. This patch is to disable unrolling for the
> loops of interest to make test cases
On Wed, Oct 30, 2019 at 1:06 PM Martin Jambor wrote:
>
> Hi,
>
> On Wed, Oct 30 2019, Jan Hubicka wrote:
> > Hi,
> > this patch fixes another place we may have missing argument summary.
> > Here the situation is that the call site being inlined has no jump
> > functions while function which is bei
On Tue, Oct 29, 2019 at 1:33 PM Wilco Dijkstra wrote:
>
> v2: Tweak testsuite options to avoid failures
>
> GCC currently defaults to -fcommon. As discussed in the PR, this is an
> ancient
> C feature which is not conforming with the latest C standards. On many
> targets
> this means global va
On Sun, Oct 20, 2019 at 3:23 PM Richard Sandiford
wrote:
>
> The increase_alignment pass was using get_vectype_for_scalar_type
> to get the preferred vector type for each array element type.
> This has the effect of carrying over the vector size chosen by
> the first successful call to all subsequ
On Sun, Oct 20, 2019 at 3:29 PM Richard Sandiford
wrote:
>
> These 11 patches just pass vec_infos to one routine each. Splitting
> them up make it easier to write the changelogs, but they're so trivial
> that it seemed better to send them all in one message.
OK.
>
> Pass a vec_info to vect_supp
On Wed, Oct 23, 2019 at 1:06 PM Richard Sandiford
wrote:
>
> mode_for_int_vector, like mode_for_vector, can sometimes return
> an integer mode or an unsupported vector mode. But no callers
> are interested in that case, and only want supported vector modes.
> This patch therefore replaces mode_fo
On Wed, Oct 30, 2019 at 10:43 AM Richard Sandiford
wrote:
>
> The series posted so far now shows how the hook would be used in practice.
> Just wanted to follow up on some points here:
>
> Richard Sandiford writes:
> > Richard Biener writes:
> >> On Wed, O
On Fri, Oct 25, 2019 at 2:32 PM Richard Sandiford
wrote:
>
> Except for one case, get_vectype_for_scalar_type_and_size calculates
> what the vector mode should be and then calls build_vector_type,
> which recomputes the mode from scratch. This patch makes it use
> build_vector_type_for_mode inste
On Fri, Oct 25, 2019 at 2:34 PM Richard Sandiford
wrote:
>
> The validation phase of vectorizable_shift used TYPE_MODE to check
> whether the shift amount vector was compatible with the shifted vector:
>
> if ((op1_vectype == NULL_TREE
>|| TYPE_MODE (op1_vectype) != TYPE_MODE (ve
On Fri, Oct 25, 2019 at 2:37 PM Richard Sandiford
wrote:
>
> This is another patch in the series to remove the assumption that
> all modes involved in vectorisation have to be the same size.
> Rather than have the target provide a list of vector sizes,
> it makes the target provide a list of vecto
On Wed, 30 Oct 2019, Joel Hutton wrote:
> On 30/10/2019 13:49, Richard Biener wrote:
> > Why do you need this? The vectorizer already creates such CTORs. Any
> > testcase that you can show?
>
> typedef long v2di __attribute__((vector_size(16)));
> v2di v;
> void
>
On October 30, 2019 7:16:43 PM GMT+01:00, "Andre Vieira (lists)"
wrote:
>Hi,
>
>In this patch I turn epilogue vectorization on by default for all
>targets. After some discussions I decided to take the following testing
>
>approach:
>
>1) I have disabled epilogue vectorization for all tests that
On October 31, 2019 8:26:47 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01645.html patch
>in the form it was committed as r263880 and later tweaks essentially
>replaced DECL_BUILT_IN with fndecl_built_in_p (or the further class
>and/or function cod
On Sat, 2 Nov 2019, Alexandre Oliva wrote:
> On Oct 30, 2019, Richard Biener wrote:
>
> > One way of operation would be to
> > generate the graph during the compilation step
>
> Stack usage is only computed during prologue/epilogue generation in RTL.
>
> > Ad
On Sun, 3 Nov 2019, Oleg Endo wrote:
> On Wed, 2019-10-30 at 10:27 +0100, Richard Biener wrote:
> >
> > Hmm, not sure - I'd like to write
> >
> > for (gimple *use_stmt : imm_stmt_uses (SSAVAR))
> >for (use_operand_p use_p : > from
> > above
The following fixes epilogue loop generation for reductions where the
reduction result isn't live.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-11-04 Richard Biener
PR tree-optimization/92301
* tree-vect-stmts.c (process_use):
On Fri, 1 Nov 2019, Joel Hutton wrote:
> On 30/10/2019 13:49, Richard Biener wrote:
> >>
> >> * expr.c (store_constructor): Add case for constructor of
> vectors.
> > Why do you need this? The vectorizer already creates such CTORs. Any
&
index dfc868fa85a..2df5addaebc 100644
> --- a/gcc/testsuite/gcc.dg/winline-10.c
> +++ b/gcc/testsuite/gcc.dg/winline-10.c
> @@ -1,9 +1,9 @@
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Winline" } */
> +/* { dg-options "-O2 -Winline -fopt-info-optimized-inline=stderr" } */
>
> struct s { int a; };
>
> -inline void f (x)/* { dg-warning "inlining .* mismatched arg" } */
> +inline void f (x)
> int x;
> {
>asm ("");
> @@ -11,7 +11,7 @@ inline void f (x) /* { dg-warning "inlining .* mismatched
> arg" } */
>
> void g (struct s x)
> {
> - f (x); /* { dg-message "called from here" } */
> + f (x); /* { dg-optimized "Inlining f.* into g" } */
> }
>
> void f (int x); /* { dg-warning "follows non-prototype
> definition" } */
> diff --git a/gcc/value-prof.c b/gcc/value-prof.c
> index 55ea0973a03..797051b57be 100644
> --- a/gcc/value-prof.c
> +++ b/gcc/value-prof.c
> @@ -1245,16 +1245,15 @@ find_func_by_profile_id (int profile_id)
> return NULL;
> }
>
> -/* Perform sanity check on the indirect call target. Due to race conditions,
> - false function target may be attributed to an indirect call site. If the
> - call expression type mismatches with the target function's type,
> expand_call
> - may ICE. Here we only do very minimal sanity check just to make compiler
> happy.
> - Returns true if TARGET is considered ok for call CALL_STMT. */
> +/* Perform sanity check on the indirect call target. Due to race conditions,
> + false function target may be attributed to an indirect call site. If the
> + call expression type mismatches with the target function's type assume
> that
> + is the case. Returns true if TARGET is considered ok for call CALL_STMT.
> */
>
> bool
> check_ic_target (gcall *call_stmt, struct cgraph_node *target)
> {
> - if (gimple_check_call_matching_types (call_stmt, target->decl, true))
> + if (gimple_call_types_likely_match_p (call_stmt, target->decl))
> return true;
>
> if (dump_enabled_p ())
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote:
>
> On 11/1/19 10:51 PM, Jeff Law wrote:
> > On 10/31/19 10:01 AM, Martin Liška wrote:
> >> Hi.
> >>
> >> operand_equal_p can properly handle situation where we have a CONSTRUCTOR
> >> where indices are NULL:
> >>
> >>if (!operand_equ
On Mon, Nov 4, 2019 at 2:35 PM Richard Biener
wrote:
>
> On Mon, Nov 4, 2019 at 10:09 AM Martin Liška wrote:
> >
> > On 11/1/19 10:51 PM, Jeff Law wrote:
> > > On 10/31/19 10:01 AM, Martin Liška wrote:
> > >> Hi.
> > >>
> > >>
On Wed, Oct 30, 2019 at 3:33 PM Wilco Dijkstra wrote:
>
> Hi Richard,
>
> > Please don't add -fcommon in lto.exp.
>
> So what is the best way to add an extra option to lto.exp?
> Note dg-lto-options completely overrides the options from lto.exp, so I can't
> use that except in tests which already
On Mon, Nov 4, 2019 at 2:55 PM David Edelsohn wrote:
>
> The change to add malloc.h to ggc-common.c broke bootstrap. system.h
> must be included before system header files. The following patch
> fixes this, committed as obvious with concurrence by Richi.
Broke x86.
I'm testing the attached.
R
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-04 Richard Biener
PR tree-optimization/92345
* tree-vect-loop.c (vect_is_simple_reduction): Return whether
we produced a reduction chain.
(vect_analyze_scalar_cycles_1): Do not
On November 4, 2019 4:30:57 PM GMT+01:00, Joel Hutton
wrote:
>First copy bounced from mailing list.
> > > On 30/10/2019 13:49, Richard Biener wrote:
> > > >>
>> > >> * expr.c (store_constructor): Add case for constructor
>of
>
ecution test
> > FAIL: libgomp.c/scan-17.c execution test
> > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O1 execution test
> > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O2 execution test
> > FAIL: libgomp.fortran/examples-4/simd-3.f90 -O3 -fomit-frame-pointer
> &
> + return nunroll;
> > +}
>
> Great :-)
>
> > @@ -23472,6 +23488,7 @@ rs6000_function_specific_save (struct
> > cl_target_option *ptr,
> > {
> >ptr->x_rs6000_isa_flags = opts->x_rs6000_isa_flags;
> >ptr->x_rs6000_isa_flags_explicit = opts->x_rs6000_isa_flags_explicit;
> > + ptr->x_unroll_small_loops = opts->x_unroll_small_loops;
> > }
>
> Yeah we shouldn't need to add that, this should all be automatic.
>
>
> Segher
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
The GCC 7 branch is now frozen for preparation of a release candidate
for the final release from the branch, GCC 7.5. All commits require
release manager approval from now on, ideally there will be no
further commits to the branch since the branch will be closed after
the GCC 7.5 release.
Thank
11-04 10:13:40.392378534
> +0100
> +++ gcc/testsuite/gfortran.dg/pr91945.f90 2019-11-04 10:13:21.272667903
> +0100
> @@ -0,0 +1,5 @@
> +! PR tree-optimization/91945
> +! { dg-do compile }
> +! { dg-options "-O3 -fstack-arrays -fno-guess-branch-probability" }
> +
&
line-asm/92352 */
> +
> +void
> +foo (int x)
> +{
> + int var[x];
> + asm volatile ("" : "+r" (var));/* { dg-error "impossible constraint in
> 'asm'" } */
> +}/* { dg-error "non-memory ou
On Tue, 5 Nov 2019, Jakub Jelinek wrote:
> On Tue, Nov 05, 2019 at 09:27:45AM +0100, Richard Biener wrote:
> > > --- gcc/gimplify.c.jj 2019-11-02 10:00:59.595253274 +0100
> > > +++ gcc/gimplify.c2019-11-05 00:21:01.585958514 +0100
> > > @@ -6235,8 +6235
y used by optimization options. */";
> +print "extern void cl_optimization_option_free (cl_optimization *ptr1);"
> +print "";
> print "/* Generator files may not have access to location_t, and don't need
> these. */"
> print "#if defin
len;
> @@ -1723,6 +1725,7 @@ lto_reader_init (void)
>lto_streamer_init ();
>file_name_hash_table
> = new hash_table (37);
> + gcc_obstack_init (&file_name_obstack);
> }
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
We have to be able to choose one signedness for the epilogue
part of the reduction - for MIN/MAX this means if we have two
both have to be of the same signedness.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-05 Richard Biener
PR tree-optimization
ng_slot);
> > > + saved_string = XOBNEWVEC (&file_name_obstack, char, len + 1);
> > > + new_slot = XOBNEWVAR (&file_name_obstack,
> > > + struct string_slot, sizeof (struct string_slot));
> > >memcpy (saved_st
));
>
> - type = build_function_type_list (integer_type_node, integer_type_node,
> + type = build_function_type_list (unsigned_type_node,
> +integer_type_node, integer_type_node,
> long_long_unsigned_type_node,
>
On Wed, 30 Oct 2019 at 03:11, H.J. Lu wrote:
> > > > > >
> > > > > > On Sun, Oct 27, 2019 at 6:33 PM Kugan Vivekanandarajah
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Richard,
> > > &g
On Mon, Nov 4, 2019 at 3:39 PM Wilco Dijkstra wrote:
>
> Hi Richard,
>
> >> > Please don't add -fcommon in lto.exp.
> >>
> >> So what is the best way to add an extra option to lto.exp?
> >> Note dg-lto-options completely overrides the options from lto.exp, so I
> >> can't
> >> use that except in
On Mon, Nov 4, 2019 at 3:49 PM Jakub Jelinek wrote:
>
> On Mon, Nov 04, 2019 at 03:23:20PM +0100, Martin Liška wrote:
> > The patch adds a new pass that identifies a series of if-elseif
> > statements and transform then into a GIMPLE switch (if possible).
> > The pass runs right after tree-ssa pas
On Fri, Oct 25, 2019 at 2:39 PM Richard Sandiford
wrote:
>
> This patch replaces vec_info::vector_size with vec_info::vector_mode,
> but for now continues to use it as a way of specifying a single
> vector size. This makes it easier for later patches to use
> related_vector_mode instead.
OK.
>
On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford
wrote:
>
> Some callers of get_same_sized_vectype were dealing with operands that
> are constant or defined externally, and so have no STMT_VINFO_VECTYPE
> available. Under the current model, using get_same_sized_vectype for
> that case is equival
On Fri, Oct 25, 2019 at 2:43 PM Richard Sandiford
wrote:
>
> After previous patches, it's now possible to make the vectoriser
> support multiple vector sizes in the same vector region, using
> related_vector_mode to pick the right vector mode for a given
> element mode. No port yet takes advantag
On Fri, Oct 25, 2019 at 2:49 PM Richard Sandiford
wrote:
>
> Although a previous patch allowed mixed vector sizes within a vector
> region, we generally still required equal vector sizes within a vector
> stmt. Specifically, vect_get_vector_types_for_stmt computes two vector
> types: the vector t
On Fri, Oct 25, 2019 at 2:51 PM Richard Sandiford
wrote:
>
> This patch adds AArch64 patterns for converting between 64-bit and
> 128-bit integer vectors, and makes the vectoriser and expand pass
> use them.
So on GIMPLE we'll see
v4si _1;
v4di _2;
_1 = (v4si) _2;
then, correct? Likewise for
On Tue, Oct 29, 2019 at 6:04 PM Richard Sandiford
wrote:
>
> If the statements in an SLP node aren't similar enough to be vectorised,
> or aren't something the vectoriser has code to handle, the BB vectoriser
> tries building the vector from scalars instead. This patch does the
> same thing if we
On Tue, Oct 29, 2019 at 6:05 PM Richard Sandiford
wrote:
>
> The BB vectoriser picked vector types in the same way as the loop
> vectoriser: it picked a vector mode/size for the region and then
> based all the vector types off that choice. This meant we could
> end up trying to use vector types t
e_use check.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-05 Richard Biener
PR tree-optimization/92280
* match.pd (BIT_FIELD_REF of CTOR): Unless the original CTOR
had a single use do not create a new CTOR.
* tree-ssa
ks,
Richard.
> Thanks,
> Feng
>
>
> From: Feng Xue OS
> Sent: Friday, October 25, 2019 11:43 AM
> To: Richard Biener
> Cc: Michael Matz; Philipp Tomsich; gcc-patches@gcc.gnu.org; Christoph
> Müllner; erick.oc...@theobroma-systems.com
> Subject: Re: [PATCH V3] Loop spli
On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote:
>
> On 10/31/19 2:16 PM, Martin Liška wrote:
> > On 10/31/19 2:01 PM, Martin Liška wrote:
> >> Hi.
> >>
> >> Based on the discussion with Honza and Richard I'm sending a proposal
> >> for conversion of param machinery into the existing option mac
On Tue, Nov 5, 2019 at 2:15 PM Aldy Hernandez wrote:
>
> The function range_int_cst_p only works with VR_RANGE's at the moment.
> This is silly because VR_ANTI_RANGE and even VR_VARYING can contain
> numeric bounds. I have fixed this oversight and have made the function
> return the bounds in MIN
On Tue, Nov 5, 2019 at 4:22 PM Martin Liška wrote:
>
> On 11/5/19 3:13 PM, Richard Biener wrote:
> > On Thu, Oct 31, 2019 at 2:17 PM Martin Liška wrote:
> >>
> >> On 10/31/19 2:16 PM, Martin Liška wrote:
> >>> On 10/31/19 2:01 PM, Martin Liška wr
On Tue, Nov 5, 2019 at 4:31 PM Andrew MacLeod wrote:
>
> On 11/5/19 8:21 AM, Aldy Hernandez wrote:
> > The base class for ranges is currently value_range_base, which is
> > rather long and cumbersome. It also occurs more often than the
> > derived class of value_range. To avoid confusion, and sa
On Tue, Nov 5, 2019 at 4:34 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Fri, Oct 25, 2019 at 2:41 PM Richard Sandiford
> > wrote:
> >>
> >> Some callers of get_same_sized_vectype were dealing with operands that
> >> are c
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-05 Richard Biener
PR tree-optimization/92371
* tree-vect-loop.c (vectorizable_reduction): Set STMT_VINFO_REDUC_DEF
on the original stmt of live stmts in the chain
ph_node *,
> Index: lto/lto.c
> ===
> --- lto/lto.c (revision 277796)
> +++ lto/lto.c (working copy)
> @@ -475,6 +476,9 @@ do_whole_program_analysis (void)
>/* We are about to launch the final LTRANS phase,
On Tue, 5 Nov 2019, Andre Vieira (lists) wrote:
> Hi,
>
> When investigating PR92317 I noticed that when we create the skip epilogue
> condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we only copy
> phi-nodes that are not constants in 'slpeel_update_phi_nodes_for_guard2'.
> This can caus
On Tue, Nov 5, 2019 at 6:53 PM Jan Hubicka wrote:
>
> > On 11/5/19 3:48 PM, Jan Hubicka wrote:
> > > > >
> > > > > stringpool.c:63 (alloc_node)47M: 2.3%
> > > > > 0 : 0.0%0 : 0.0%0 : 0.0% 1217k
> > > > > ipa-prop.c:4480 (ipa_read_edge_inf
On Tue, Nov 5, 2019 at 9:10 PM Richard Sandiford
wrote:
>
> As explained in the comment, vectorizable_call needs more work to
> support mixtures of sizes. This avoids testsuite fallout for
> later SVE patches.
>
> Was originally going to be later in the series, but applying it
> before 11/n seems
On Tue, Nov 5, 2019 at 9:25 PM Richard Sandiford
wrote:
>
> Patch 12/n makes the AArch64 port add four entries to
> autovectorize_vector_modes. Each entry describes a different
> vector mode assignment for vector code that mixes 8-bit, 16-bit,
> 32-bit and 64-bit elements. But if (as usual) the
On Wed, Nov 6, 2019 at 11:21 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Nov 5, 2019 at 9:25 PM Richard Sandiford
> > wrote:
> >>
> >> Patch 12/n makes the AArch64 port add four entries to
> >> autovectorize_vector_modes. Each
On Wed, Nov 6, 2019 at 12:02 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Wed, Nov 6, 2019 at 11:21 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener writes:
> >> > On Tue, Nov 5, 2019 at 9:25 PM Richard Sandiford
>
On Mon, Nov 4, 2019 at 4:26 PM Richard Sandiford
wrote:
>
> Once vect_analyze_loop has found a valid loop_vec_info X, we carry
> on searching for alternatives if (1) X doesn't satisfy simdlen or
> (2) we want to vectorise the epilogue of X. I have a patch that
> optionally adds a third reason: we
On Mon, Nov 4, 2019 at 4:29 PM Richard Sandiford
wrote:
>
> The number of iterations of an epilogue loop is always smaller than the
> VF of the main loop. vect_analyze_loop_costing was taking this into
> account when deciding whether the loop is cheap enough to vectorise,
> but that has no effect
On Mon, Nov 4, 2019 at 4:30 PM Richard Sandiford
wrote:
>
> With a later patch I saw a case in which we peeled a single iteration
> for gaps but didn't need to peel further iterations to make up a full
> vector. We then tried to vectorise the single-iteration epilogue.
But when peeling for gaps
On Mon, Nov 4, 2019 at 4:30 PM Richard Sandiford
wrote:
>
> With later patches, we're able to vectorise the epilogues of these tests
> on AArch64 and so get two instances of "vectorizing stmts using SLP".
> Although it would be possible with a bit of effort to predict when
> this happens, it doesn
On Tue, Nov 5, 2019 at 3:25 PM Richard Sandiford
wrote:
>
> This patch makes two tweaks to vectorizable_conversion. The first
> is to use "modifier" to distinguish between promotion, demotion,
> and neither promotion nor demotion, rather than using a code for
> some cases and "modifier" for other
On Tue, Nov 5, 2019 at 3:27 PM Richard Sandiford
wrote:
>
> vectorizable_assignment handles true SSA-to-SSA copies (which hopefully
> we don't see in practice) and no-op conversions that are required
> to maintain correct gimple, such as changes between signed and
> unsigned types. These cases sh
On Tue, Nov 5, 2019 at 3:28 PM Richard Sandiford
wrote:
>
> vect_analyze_loop_costing uses two profitability thresholds: a runtime
> one and a static compile-time one. The runtime one is simply the point
> at which the vector loop is cheaper than the scalar loop, while the
> static one also takes
On Tue, Nov 5, 2019 at 3:29 PM Richard Sandiford
wrote:
>
> This patch adds a mode in which the vectoriser tries each available
> base vector mode and picks the one with the lowest cost. For now
> the behaviour is behind a default-off --param, but a later patch
> enables it by default for SVE.
>
On Tue, Nov 5, 2019 at 3:31 PM Richard Sandiford
wrote:
>
> We didn't take the cost of generating loop masks into account, and so
> tended to underestimate the cost of loops that need multiple masks.
OK.
>
> 2019-11-05 Richard Sandiford
>
> gcc/
> * tree-vect-loop.c (vect_estimate_min
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-11-06 Richard Biener
* tree-vect-loop.c (vectorizable_reduction): Remember reduction
PHI. Use STMT_VINFO_REDUC_IDX to skip the reduction operand.
Simplify single_defuse_cycle condition
On Wed, Nov 6, 2019 at 1:22 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Nov 4, 2019 at 4:30 PM Richard Sandiford
> > wrote:
> >>
> >> With a later patch I saw a case in which we peeled a single iteration
> >> for gaps but didn
801 - 900 of 26740 matches
Mail list logo
