Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)
On 30/10/18 08:36, Richard Biener wrote:
On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
wrote:
I want to submit some vectorizer patches, what would be a suitable
regression test?
I am sure you have testcases, no? For new features please make them
dg-do run ones by checking correctness.
For the dot product / widen_sum -> madd transformations to trigger,
I need an in-tree port with a named pattern matched by
smadd_widen_optab or umadd_widen_optab, with an input matching
PREFERRED_SIMD_VECTOR_MODE, and hence an output twice that
size (and that pattern must not be eclipsed by existing
[us]sum_widen_optab and [us]dot_prod_optab matches).
I can't find any such port in the tree. Indeed, not any
{u,}madd4 pattern at all.
I've heard that arm cortex-m4 hardware acctually supports a madd vector
operation
(V2HI -> V2SI), is that true?
Would the test be suitable if it made the arm target,
with a patch added to add a suitable madd pattern, and my vectorizer
patch added,
use that madd pattern?
Or could I add an imaginary madd vector extension instruction to the arc for
that purpose? But then, it wouldn't actually execute, as it's just a
made-up instruction;
nor would the vectorization test be included in a test run for an actual.
Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)
On Thu, Nov 1, 2018 at 10:42 AM Joern Wolfgang Rennecke
wrote:
>
>
> On 30/10/18 08:36, Richard Biener wrote:
> > On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
> > wrote:
> >> I want to submit some vectorizer patches, what would be a suitable
> >> regression test?
> > I am sure you have testcases, no? For new features please make them
> > dg-do run ones by checking correctness.
> For the dot product / widen_sum -> madd transformations to trigger,
> I need an in-tree port with a named pattern matched by
> smadd_widen_optab or umadd_widen_optab, with an input matching
> PREFERRED_SIMD_VECTOR_MODE, and hence an output twice that
> size (and that pattern must not be eclipsed by existing
> [us]sum_widen_optab and [us]dot_prod_optab matches).
>
> I can't find any such port in the tree. Indeed, not any
> {u,}madd4 pattern at all.
>
> I've heard that arm cortex-m4 hardware acctually supports a madd vector
> operation
> (V2HI -> V2SI), is that true?
Don't think there's a single instruction that does that.
smlad is the closest IIRC and checking with the Arm ARM, that's V2HI
-> V2HI for the multiplication and then an accumulation with a 32 bit
accumulator. Thus effectively a add (reduc_add (mult(v2hi , v2hi)),
si) , but we don't support any vector forms using the integer register
set for the M profile architecture as of today in gcc. Thus you
probably need 2 smlald instructions to achieve this IIUC . We do have
a dot product optab in the arm backend but that's with Advanced simd
which isn't in the M profile.
regards
Ramana
>
> Would the test be suitable if it made the arm target,
> with a patch added to add a suitable madd pattern, and my vectorizer
> patch added,
> use that madd pattern?
>
> Or could I add an imaginary madd vector extension instruction to the arc for
> that purpose? But then, it wouldn't actually execute, as it's just a
> made-up instruction;
> nor would the vectorization test be included in a test run for an actual.
Patches for gcc/fortran and libgfortran need to be discussed and approved on fortran mailing list
Hi, a gentle reminder: Patches which touch gcc/fortran or libgfortran need to be discussed on the fortran mailing list and approved by a reviewer. There have been a couple of commits recently where this wasn't followed, please remember to do so in the future. Regards Thomasa
gcc-7-20181101 is now available
Snapshot gcc-7-20181101 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20181101/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 265734 You'll find: gcc-7-20181101.tar.xzComplete GCC SHA256=77384d15a8674fcd4ae37b83d887b2de756ccfc8f48799ea85f404b3a9a67a6b SHA1=01ac0b5cb3ec0d8eaa74e6f8edf857457809e708 Diffs from 7-20181025 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
LRA reload produces invalid insn
I'm running the testsuite on the pdp11 target, and I get a failure when using
LRA that works correctly with the old allocator. The issue is that LRA is
producing an insn that is invalid (it violates the constraints stated in the
insn definition).
The insn in the IRA dump looks like this:
(insn 240 238 241 13 (set (reg/f:HI 155)
(plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6])))
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))
(nil)))
(note that R5 is FRAME_POINTER_REGNUM.)
The reload dump from LRA shows this:
(insn 240 238 241 13 (set (reg/f:HI 5 r5 [155])
(plus:HI (reg/f:HI 6 sp)
(const_int 12 [0xc])))
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))
(nil)))
But that's not valid because ADD is a two-operand instruction:
(define_insn_and_split "addhi3"
[(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
(plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
(match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]
The old allocator produces two insns for this:
(insn 443 238 240 13 (set (reg/f:HI 5 r5 [155])
(const_int 12 [0xc]))
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
25 {movhi}
(nil))
(insn 240 443 241 13 (set (reg/f:HI 5 r5 [155])
(plus:HI (reg/f:HI 5 r5 [155])
(reg/f:HI 6 sp)))
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 6 sp)
(const_int 12 [0xc]))
(nil)))
which is the correct sequence given the matching operand constraint in the
define_insn.
Is this an LRA bug, or is there something I need to do in the target to prevent
this happening?
paul
Re: LRA reload produces invalid insn
On 11/1/18 7:25 PM, Paul Koning wrote: > I'm running the testsuite on the pdp11 target, and I get a failure when using > LRA that works correctly with the old allocator. The issue is that LRA is > producing an insn that is invalid (it violates the constraints stated in the > insn definition). [snip] > which is the correct sequence given the matching operand constraint in the > define_insn. > > Is this an LRA bug, or is there something I need to do in the target to > prevent this happening? What do you mean by "old allocator"? Just an older revision? Does it work before my revision 264897 commit and broken after? If so, could you try the following to see whether that fixes things for you? https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html My commit above exposed some latent LRA bugs and my patch above tries to fix issues similar to what you're seeing. Peter
Re: LRA reload produces invalid insn
Hi Peter, On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote: > On 11/1/18 7:25 PM, Paul Koning wrote: > > I'm running the testsuite on the pdp11 target, and I get a failure when > > using LRA that works correctly with the old allocator. The issue is that > > LRA is producing an insn that is invalid (it violates the constraints > > stated in the insn definition). > [snip] > > which is the correct sequence given the matching operand constraint in the > > define_insn. > > > > Is this an LRA bug, or is there something I need to do in the target to > > prevent this happening? > > What do you mean by "old allocator"? I think Paul just means old reload. Segher
Ping: Some MIPS patch need review and approval.
Ping ? On Wed, Oct 31, 2018 at 8:30 PM Paul Hua wrote: > > Hi, GCC steering committee: > > There are some MIPS patches that need to be reviewed and approved. > > [PATCH v3 0/6] [MIPS] Reorganize the loongson march and extensions > instructions set. [1] > [PATCH v3 1/6] [MIPS] Split Loongson (MMI) from loongson3a. [2] > [PATCH v3 2/6] [MIPS] Split Loongson EXTensions (EXT) instructions > from loongson3a. [3] > [PATCH v3 3/6] [MIPS] Add Loongson EXTensions R2 (EXT2) instructions > support. [4] > [PATCH v3 4/6] [MIPS] Add Loongson 3A1000 processor support. [5] > [PATCH v3 5/6] [MIPS] Add Loongson 3A2000/3A3000 processor support. [6] > [PATCH v3 6/6] [MIPS] Add Loongson 2K1000 processor support. [7] > [PATCH v2] MIPS: Default to --with-llsc for the R5900 Linux target as well. > [8] > > [1] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00908.html > [2] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00912.html > [3] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00909.html > [4] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00910.html > [5] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00914.html > [6] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00911.html > [7] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00913.html > [8] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01205.html > > > The MIPS Port Maintainer Matthew Fortune seems to > have no activity for a long time. > > Thanks. > > Paul Hua.
Re: LRA reload produces invalid insn
On 11/1/18 8:40 PM, Segher Boessenkool wrote: > Hi Peter, > > On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote: >> On 11/1/18 7:25 PM, Paul Koning wrote: >>> I'm running the testsuite on the pdp11 target, and I get a failure when >>> using LRA that works correctly with the old allocator. The issue is that >>> LRA is producing an insn that is invalid (it violates the constraints >>> stated in the insn definition). >> [snip] >>> which is the correct sequence given the matching operand constraint in the >>> define_insn. >>> >>> Is this an LRA bug, or is there something I need to do in the target to >>> prevent this happening? >> >> What do you mean by "old allocator"? > > I think Paul just means old reload. In that case, my patch may still help. Peter
Re: LRA reload produces invalid insn
On 11/01/2018 08:25 PM, Paul Koning wrote:
I'm running the testsuite on the pdp11 target, and I get a failure when using
LRA that works correctly with the old allocator. The issue is that LRA is
producing an insn that is invalid (it violates the constraints stated in the
insn definition).
The insn in the IRA dump looks like this:
(insn 240 238 241 13 (set (reg/f:HI 155)
(plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6])))
"/Users/pkoning/Documents/svn/combined/gcc/testsuite/gcc.c-torture/execute/builtins/strcat-chk.c":68:7
68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -58 [0xffc6]))
(nil)))
(note that R5 is FRAME_POINTER_REGNUM.)
Is this an LRA bug, or is there something I need to do in the target to prevent
this happening?
It is hard to say whose code is responsible for this. It might be a
wrong machine-dependent code or a LRA bug.
Paul, could you send me full LRA dump file (.reload). It might help me
to say more specific reason for the bug. LRA has iterated sub-passes
and the full dump can say where LRA started to behave wrongly.
