public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/108292] [13 Regression] wrong code with vector compare & mask at -O1 and above
Date: Thu, 05 Jan 2023 19:15:16 +0000	[thread overview]
Message-ID: <bug-108292-4-mEq8d1ztV6@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108292-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
> 
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression testing).  The goal is to capture the original comparison (at
> the top of the BB), and avoid/ignore the actual comparison that we may have
> converted to.
> Sorry again to the inconvenience.  Please let me know what you think.

I don't like that much (of course, Uros is the maintainer so his call).
But, I think we should avoid bundling the code generation changes (the dropping
of ct or cf checks for negate_cc_compare_p; if that is a win, it should be
proven separately but it isn't clear if it is) and the patch just causes
further dead variables which the current code already has many.
What is the point of orig_code when code is already dead except for this newly
added REG_EQUAL note?  Why can't just code contain it?
As for the floating point stuff, yes, the - 1 would be an option, but perhaps
should be used only if we need to reverse floating point comparison?
If we introduce a bool for swap_ct_cf, then it seems pointless to also actually
swap ct/cf and recompute diff in all the spots, just set swap_ct_cf and
swap/recompute diff only if the bool is set and we need to look at ct/cf/diff.

  parent reply	other threads:[~2023-01-05 19:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05  6:28 [Bug rtl-optimization/108292] New: " zsojka at seznam dot cz
2023-01-05 12:54 ` [Bug rtl-optimization/108292] " jakub at gcc dot gnu.org
2023-01-05 12:54 ` jakub at gcc dot gnu.org
2023-01-05 14:07 ` jakub at gcc dot gnu.org
2023-01-05 14:58 ` jakub at gcc dot gnu.org
2023-01-05 17:10 ` roger at nextmovesoftware dot com
2023-01-05 17:11 ` jakub at gcc dot gnu.org
2023-01-05 17:25 ` jakub at gcc dot gnu.org
2023-01-05 17:28 ` jakub at gcc dot gnu.org
2023-01-05 18:06 ` roger at nextmovesoftware dot com
2023-01-05 18:51 ` roger at nextmovesoftware dot com
2023-01-05 19:15 ` jakub at gcc dot gnu.org [this message]
2023-01-05 19:25 ` ubizjak at gmail dot com
2023-01-05 19:51 ` cvs-commit at gcc dot gnu.org
2023-01-05 19:53 ` hjl.tools at gmail dot com
2023-01-05 20:29 ` roger at nextmovesoftware dot com
2023-01-05 20:32 ` roger at nextmovesoftware dot com
2023-01-06  9:37 ` jakub at gcc dot gnu.org
2023-01-06  9:54 ` [Bug target/108292] " cvs-commit at gcc dot gnu.org

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=bug-108292-4-mEq8d1ztV6@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).