public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jeff Law <law@redhat.com>
Cc: Henri Cloetens <henri.cloetens@blueice.be>,
	gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: How to recognize registers after reload ?.
Date: Thu, 22 Oct 2020 17:24:38 -0500	[thread overview]
Message-ID: <20201022222438.GX2672@gate.crashing.org> (raw)
In-Reply-To: <ec9418ca-17bd-231a-6abd-ef69c87f4a0a@redhat.com>

On Thu, Oct 22, 2020 at 03:30:08PM -0600, Jeff Law via Gcc-help wrote:
> On 10/22/20 2:02 AM, Henri Cloetens wrote:
> > Motivation for the split was problems with the "combine" step. Suppose
> > following code:
> >     *a = 10.
> >     Even if my front_end (define_expand) splits this in
> >     r100 = 10
> >    *r101 = r100
> >    the combine step, if these is only one movesi_internal, willl group
> > it again, to then find out
> >    there is no instruction pattern.
> 
> This is an indication the insn's condition or operand's predicate or
> operand constraints are wrong.

Yes, but I do not understand what Henri means at all.

On one side, combine will try to combine any such pair, and then it
does discover there is no insn for that, and then not do the
combination.  This is exactly what combine is supposed to do.

On the other side, it could mean combine *does* allow the combo.  Then,
you *do* have a define_insn for it, or it would *not* allow it.  And
then some time later that is a problem?  But that has nothing to do with
combine, that just is a buggy machine description.

(My money is on the predicate btw ;-) )


Segher

  reply	other threads:[~2020-10-22 22:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22  8:02 Henri Cloetens
2020-10-22 21:30 ` Jeff Law
2020-10-22 22:24   ` Segher Boessenkool [this message]
2020-10-22 23:47     ` Jeff Law
2020-10-23  7:28       ` Henri Cloetens
2020-10-23  7:35         ` AW: " Stefan Franke
2020-10-23  7:56           ` Henri Cloetens
2020-10-23 10:20           ` Segher Boessenkool
2020-10-23 11:38             ` Henri Cloetens
2020-10-23 10:02         ` 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=20201022222438.GX2672@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=henri.cloetens@blueice.be \
    --cc=law@redhat.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).