public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: Hongyu Wang <wwwhhhyyy333@gmail.com>
Cc: Hongyu Wang <hongyu.wang@intel.com>,
	Hongtao Liu <hongtao.liu@intel.com>,
	 "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] [i386] GLC tuning: Break false dependency for dest register.
Date: Fri, 14 Jan 2022 09:37:28 +0100	[thread overview]
Message-ID: <CAFULd4YPDeRe4trnxCJSvL5nGZV=i8qFWux6XuC_hWn_V881MA@mail.gmail.com> (raw)
In-Reply-To: <CA+OydWm2KHJpPaL9J=WH+o4y8z-o+fe_u0Djn5Tnzn_xWWArpw@mail.gmail.com>

On Fri, Jan 14, 2022 at 7:11 AM Hongyu Wang <wwwhhhyyy333@gmail.com> wrote:
>
> > > No, the approach is wrong. You have to solve output clearing on RTL
> > > level, please look at how e.g. tzcnt false dep is solved:
> >
> > Actually we have considered such approach before, but we found we need
> > to break original define_insn to remove the mask/rounding subst,
> > since define_split could not adopt subst, and that would add 6 more
> > define_insn_and_split and 4 define_insn for each instruction. We think
> > such approach would introduce too much redundant code.
> >
> > Do you think the code size increment is acceptable?
>
> Also that 100+ more patterns increases maintenance effort. If we split
> them at epilogue_complete stage,
> it seems not much difference to put it under output template...

In the proposed patch, if the output register is also mentioned in the
input, then clearing before insn will clear the value in the input
register. The solution in the i386.md also takes care of this issue.

Uros.

  reply	other threads:[~2022-01-14  8:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-13  7:28 Hongyu Wang
2022-01-13  7:41 ` Uros Bizjak
2022-01-14  5:38   ` Hongyu Wang
2022-01-14  6:03     ` Hongyu Wang
2022-01-14  8:37       ` Uros Bizjak [this message]
2022-01-14 13:44         ` Hongyu Wang
2022-01-14 15:49           ` Uros Bizjak
2022-01-15 16:39             ` Hongyu Wang
2022-01-15 16:43               ` Uros Bizjak
2022-01-16  4:22                 ` Hongtao Liu
2022-01-19  0:00                   ` [PATCH] i386: Fix GLC tuning with -masm=intel [PR104104] Jakub Jelinek
2022-01-19  1:01                     ` Wang, Hongyu
2022-01-19  1:09                     ` Hongtao Liu
2022-01-19  1:40                       ` [PATCH] i386: Fix *aes<aeswideklvariant>u8 Jakub Jelinek
2022-01-19  1:47                         ` Hongtao Liu
2022-01-14  8:17     ` [PATCH] [i386] GLC tuning: Break false dependency for dest register Uros Bizjak

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='CAFULd4YPDeRe4trnxCJSvL5nGZV=i8qFWux6XuC_hWn_V881MA@mail.gmail.com' \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=hongyu.wang@intel.com \
    --cc=wwwhhhyyy333@gmail.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).