public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Henri Cloetens <henri.cloetens@blueice.be>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Issue with reload
Date: Fri, 6 Nov 2020 21:41:31 +0100	[thread overview]
Message-ID: <8d71f6dd-afdc-cf0e-563d-bd3867d961a7@blueice.be> (raw)
In-Reply-To: <20201103172357.GK2672@gate.crashing.org>

Hello Segher, all,

I have the impression there is a small bug in the front-end.

//#define LOAD_EXTEND_OP(MODE) ZERO_EXTEND
#define LOAD_EXTEND_OP(MODE) UNKNOWN      // HACK HENRI !!.
(this is in my back-end)

I have to turn the LOAD_EXTEND_OP(MODE) to UNKNOWN.

The issue seems to be following:
- There are operations in the code of the type
R100:SI = zero_extend(R101:HI)
- Now, during reload, R101:HI is moved on the stack.
- Then, internally in the compiler, there is confusion on the 
zero_extend operator.
   a. If the load-extend-mode is ZERO_EXTEND:
       there is confusion as to use the MOVHI instruction or the 
ZERO_EXTEND instruction.
       (they both do the same.) This seems to lead to the strange bugs.
       (It seems to me there are optimizers that recognize the 
ZERO_EXTEND as MOVHI, and others
        that dont, leading to the crashes.)
   b. If I turn it off, all seems to go OK.
- So, I turned it off ... Hope this does not lead to problems.

Best Regards,

Henri.


On 11/3/20 6:23 PM, Segher Boessenkool wrote:
> Hi Henri,
>
> On Tue, Nov 03, 2020 at 04:25:32PM +0100, Henri Cloetens wrote:
>>> 583: r990:SI=zero_extend(r378:SI#0)
>> - The statement (r378:SI#0) takes the '0' subreg form reg r378:SI.
>> (shorthand in the reload dump.)
> And it doesn't say what mode subreg it is (QImore or HImode here).
> There are multiple cases like this, where the abbreviated RTL is not
> conclusive (so cannot be parsed back).
>
>>> (define_insn "zero_extendhisi2_internal"
>>>    [(set (match_operand:SI 0 "gpc_reg_operand" "=r,r,r")
>>>          (zero_extend:SI (match_operand:HI 1 "movhi_operand_0"
>> "Z,C,r")))]
>>
>> - However, the predicate "r" in the statement above, does not allow a
>> subreg.
> Yes it does.  See register_operand in recog.c for example.  It is of
> course possible your gpc_reg_operand doesn't allow it (bad idea, but I
> don't know your code).
>
> You would normally start the gpc_reg_operand code with something like
>
>    if (SUBREG_P (op))
>      op = SUBREG_REG (op);
>
> (as well as pretty much all other register operand predicates).
>
>
> Segher



      parent reply	other threads:[~2020-11-06 20:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 13:00 Henri Cloetens
2020-11-03 15:25 ` Henri Cloetens
2020-11-03 17:23   ` Segher Boessenkool
2020-11-03 18:49     ` Henri Cloetens
2020-11-06 20:41     ` Henri Cloetens [this message]

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=8d71f6dd-afdc-cf0e-563d-bd3867d961a7@blueice.be \
    --to=henri.cloetens@blueice.be \
    --cc=gcc-help@gcc.gnu.org \
    --cc=segher@kernel.crashing.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).