public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Stefan Franke" <s.franke@bebbosoft.de>
To: "'gcc-help'" <gcc-help@gcc.gnu.org>
Subject: AW: How to recognize registers after reload ?.
Date: Fri, 23 Oct 2020 09:35:20 +0200	[thread overview]
Message-ID: <0cd001d6a90f$0fd96f80$2f8c4e80$@bebbosoft.de> (raw)
In-Reply-To: <734be852-33ed-ee19-88a9-99a5905db5cf@blueice.be>



> -----Ursprüngliche Nachricht-----
> Von: Gcc-help <gcc-help-bounces@gcc.gnu.org> Im Auftrag von Henri
> Cloetens
> Gesendet: Freitag, 23. Oktober 2020 09:29
> An: Jeff Law <law@redhat.com>; Segher Boessenkool
> <segher@kernel.crashing.org>
> Cc: gcc-help <gcc-help@gcc.gnu.org>
> Betreff: Re: How to recognize registers after reload ?.
> 
> Hello Segher, Jeff,
> 
> - The machine is indeed such that for each operation there is only one
>    non-register operand possible.
> - Take a first example, to describe the problem with the combine:
> void set_to_one(int *a)
> {
> *a = 1 ;
> }
> 
> In the machine, this becomes:
> 
> R30 = 1  // move immediate to register
> [R20] = R30 // move to *a
> return
> 
> Now, to get this, there is not one movsi - pattern, because if there is only
> one, combine will combine both moves into something like [R20] = 1 and this
> does not exist, and combine crashes. So, there are 2 moves:
> /movesi_internal_fromreg/ (moving from a register to memory or register)
> /movesi_internal_toreg/ (moving from immediate, memory, register to
> register).
> 
> This is all nice and fine, until the reload step. In case the number of internal
> registers is exceeded, stuff needs to go on the stack. Now, suppose I have
> the operation
> 
> R30 = 1
> 
> and the compiler wants to put R30 on the stack, it sees this is not possible,
> and will make a helper move :
> 
> R30 = 1 (old one)
> R100 = R30
> 
> and then, it will try to put R100 on the stack. Now, to do the move,
> R100 = R30, it calls the
> /movsi/ pattern in the machine description. Only, it declares in the RTX
> R100 as a register operand,
> which it is not, or not entirely. It is a stack operand, but my /define_expand
> movsi/ recognizes it as a register operand, end emits
> /movesi_internal_toreg/, while it should emit /movesi_internal_fromreg/,
> and the whole system ends in an endless loop.
> To solve this decently, I need to find in the /define_expand movsi/ if
> R100 is a stack operand or not.
> There is one way, that is to implement TARGET_SECONDARY_RELOAD, have
> that parse all the arguments, put it in an operand database, and have
> /define_expand movsi/ interrogate this database. Now, I will only do that if
> there is no other option.
> 
> Best Regards,
> 
> Henri.
> >

Henri,

it seems your define_expand for movsi is too narrow. It should accept all mandatory forms. The distinction - to register/memory - should be done in movsi itself. There is also no need for a database to distinguish.

Regards

Stefan


  reply	other threads:[~2020-10-23  7:35 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
2020-10-22 23:47     ` Jeff Law
2020-10-23  7:28       ` Henri Cloetens
2020-10-23  7:35         ` Stefan Franke [this message]
2020-10-23  7:56           ` AW: " 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='0cd001d6a90f$0fd96f80$2f8c4e80$@bebbosoft.de' \
    --to=s.franke@bebbosoft.de \
    --cc=gcc-help@gcc.gnu.org \
    --cc=stefan@franke.ms \
    /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).