public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>,
	"Kewen.Lin" <linkw@linux.ibm.com>
Cc: Bill Schmidt <wschmidt@linux.ibm.com>,
	Hongtao Liu <hongtao.liu@intel.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	David Edelsohn <dje.gcc@gmail.com>
Subject: Re: [PATCH] rs6000/test: Adjust some cases due to O2 vect [PR102658]
Date: Mon, 11 Oct 2021 10:23:03 -0600	[thread overview]
Message-ID: <9bb2743f-cd23-5b7d-6d9d-9917e591377f@gmail.com> (raw)
In-Reply-To: <20211011153050.GV10333@gate.crashing.org>

On 10/11/21 9:30 AM, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Oct 11, 2021 at 10:47:00AM +0800, Kewen.Lin wrote:
>> As PR102658 shows, commit r12-4240 enables vectorization at O2,
>> some cases need to be adjusted accordingly for rs6000 port.
>>
>> - For target specific test cases, this adds -fno-tree-vectorize
>> to retain original test points, otherwise vectorization can
>> make some expected scalar instructions gone or generate some
>> unexpected instructions for vector construction.
> 
> Ah good choice.
> 
>> - For generic test cases, it follows the existing suggested
>> practice with necessary target/xfail selector.
> 
> Not such a great choice.  Many of those tests do not make sense with
> vectorisation enabled.  This should have been thought about, in some
> cases resulting in not running the test with vectorisation enabled, and
> in some cases duplicating the test, once with and once without
> vectorisation.

The tests detect bugs that are present both with and without
vetctorization, so they should pass both ways.  That they don't
tells us that that the warnings need work (they were written with
an assumption that doesn't hold anymore).  We need to track that
work somehow, but simply xfailing them without making a record
of what underlying problem the xfails correspond to isn't the best
way.  In my experience, what works well is opening a bug for each
distinct limitation (if one doesn't already exist) and adding
a reference to it as a comment to the xfail.

> 
> But you are just following established practice, so :-)
> 
>> -  struct A1 a = { 0, { 1 } };   // { dg-warning "\\\[-Wstringop-overflow" "" { target { i?86-*-* x86_64-*-* } } }
>> +  struct A1 a = { 0, { 1 } };   // { dg-warning "\\\[-Wstringop-overflow" "" { target { i?86-*-* x86_64-*-* powerpc*-*-* } } }

As I mentioned in the bug, when adding xfails for regressions
please be sure to reference the bug that tracks the underlying
root cause.  There may be multiple problems, and we need to
identify what it is in each instance.  As the author of
the tests I can help with that but not if I'm not in the loop
on these changes (it would seem prudent to get the author's
thoughts on such sweeping changes to their work).

I discussed one of these failures with Hongtao in detail at
the time autovectorization was being enabled and made the same
request then but I didn't realize the problem was so pervasive.

In addition, the target-specific conditionals in the xfails are
going to be difficult to maintain.  It might be okay for one or
two in a single test but for so many we need a better solution
than that.  If autovectorization is only enabled for a subset
of targets then a solution might be to add a new DejagGNU test
for it and conditionalize the xfails on it.

Martin

> 
> I don't know if powerpc*-*-* is the correct choice in all these cases.
> Sometimes it might have to be powerpc*-*-linux* or similar.  We'll find
> out :-)
> 
> (An xfail causes XPASS if the test does *not* fail).
> 
>> +/* Now O2 enables vectorization by default, which generates unexpected float
>> +   conversion for vector construction, so simply disable it.  */
> 
> It is good to see these comments.  I love puzzles, but not in the
> testsuite! :-)
> 
> Okay for trunk.  Thanks!
> 
> 
> Segher
> 


  reply	other threads:[~2021-10-11 16:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11  2:47 Kewen.Lin
2021-10-11 15:30 ` Segher Boessenkool
2021-10-11 16:23   ` Martin Sebor [this message]
2021-10-11 17:43     ` Segher Boessenkool
2021-10-11 20:07       ` Martin Sebor
2021-10-12  2:31         ` Hongtao Liu
2021-10-12 15:49           ` Martin Sebor
2021-10-12 16:18             ` Segher Boessenkool
2021-10-12 17:15               ` Martin Sebor
2021-10-12 17:45                 ` Jeff Law
2021-10-12 18:01                 ` Segher Boessenkool
2021-10-13  3:34             ` Hongtao Liu
2021-10-13  6:29               ` Hongtao Liu
2021-10-13  7:43                 ` Kewen.Lin
2021-10-13 14:36                   ` Martin Sebor
2021-10-14  7:11                   ` [PATCH] Adjust testcase for O2 vectorization liuhongt
2021-10-14  7:52                     ` Bernhard Reutner-Fischer
2021-10-14 10:56                     ` Kewen.Lin
2021-10-15  7:11                       ` Kewen.Lin
2021-10-18  4:47                         ` Hongtao Liu
2021-10-15 15:37                     ` Martin Sebor
2021-10-18  4:38                       ` Hongtao Liu
2021-10-18 15:11                         ` Martin Sebor
2021-10-19  9:03                           ` liuhongt
2021-10-20 11:34                             ` Christophe Lyon
2021-10-21  1:20                               ` Hongtao Liu
2021-10-21  2:06                                 ` Hongtao Liu
2021-10-21  2:07                                   ` Hongtao Liu
2021-10-12 18:11         ` [PATCH] rs6000/test: Adjust some cases due to O2 vect [PR102658] Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9bb2743f-cd23-5b7d-6d9d-9917e591377f@gmail.com \
    --to=msebor@gmail.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=linkw@linux.ibm.com \
    --cc=segher@kernel.crashing.org \
    --cc=wschmidt@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).