public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Henri Cloetens <henri.cloetens@blueice.be>
To: gcc-help@gcc.gnu.org
Subject: Re: Issue during combine.
Date: Mon, 19 Oct 2020 17:55:55 +0200	[thread overview]
Message-ID: <2ade57f1-ff38-553c-0e06-1cbb445f5d4e@blueice.be> (raw)
In-Reply-To: <df98a656-1f20-1b68-de60-5936df4c5751@blueice.be>

Hello all,

This seems to be a bug in the non-port code of the compiler.
It crashes in
/rtx simplify_subreg(machine_mode outer_mode, rtx op, machine_mode 
inner_mode, poly_uint64 byte)/

The crash is, because this function is called with inner_mode = 
Voidmode. (And seems illegal.)

It seems to me this "illegal" mode is the result of the /combine/ step, 
trying to "improve" by doing combinations of
instructions "at random". Here, it tries a "combination" that does not 
make sense, but it causes a crash in
the abovementioned routine. When I change the code, so that this routine 
returns 0 (=fail the operation), it passes
the '263 step without errors. The meaningless combination is refused 
elsewhere. It is not done.

Best Regards,

Henri.


On 10/19/2020 02:53 PM, Henri Cloetens wrote:
> Hello all,
>
> I am building a gcc 9.2.0 custom compiler, and I am running in an 
> issue during step 263, combine.
>
> Before combine:
>
> /(insn 2354 2352 1743 175 (set (reg/v:SI 197 [ dig ])//
> //        (if_then_else (eq (subreg:QI (reg:SI 632) 1)//
> //                (const_int 1 [0x1]))//
> //            (reg:SI 708)//
> //            (reg/v:SI 197 [ dig ]))) 
> "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":771:6 35 
> {select_internal3}//
> //     (expr_list:REG_DEAD (reg:SI 708)//
> //        (expr_list:REG_DEAD (reg:SI 632)//
> //            (nil))))//
> //(insn 1743 2354 124 175 (set (mem:QI (reg:SI 316 [ ivtmp.118 ]) [0 
> *s_304+0 S1 A8])//
> //        (subreg:QI (reg/v:SI 197 [ dig ]) 0)) 
> "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":772:13 6 
> {movqi_internal}//
> //     (expr_list:REG_DEAD (reg:SI 316 [ ivtmp.118 ])//
> //        (expr_list:REG_DEAD (reg/v:SI 197 [ dig ])//
> //            (nil))))/
>
> This is during the combine-step transformed into:
>
> /(insn 1743 2354 124 175 (set (mem:QI (reg:SI 316 [ ivtmp.118 ]) [0 
> *s_304+0 S1 A8])//
> //        (subreg:QI (if_then_else (eq (subreg:QI (reg:SI 632) 1)//
> //                    (const_int 1 [0x1]))//
> //                (reg:SI 708)//
> //                (reg/v:SI 197 [ dig ])) 0)) 
> "/home/henri/blueICe/gcc/newlib/newlib/libc/stdlib/dtoa.c":772:13 6 
> {movqi_internal}//
> //     (expr_list:REG_DEAD (reg:SI 316 [ ivtmp.118 ])//
> //        (expr_list:REG_DEAD (reg/v:SI 197 [ dig ])//
> //            (nil))))/
>
> This, of course, is not correct any more. Now, how should I prevent 
> this ?, the pattern is defined in the .md-file as:
>
> /(define_insn "movqi_internal" //
> //[(set (match_operand:QI 0 "movqi_operand_0" 
> "=r,r,r,r,r,r,u,u,W,t,r,c,*c*l,*h,*h,y")//
> //(match_operand:QI 1 "movqi_operand_1" "O,k,i,r,W,t,W,t,r,r,*h,u, 
> r,   r, 0,y"))]/
>
> /.../
> and /movqi_operand_1/ is defined as:
>
> /(define_predicate "movqi_operand_1"//
> //  (ior (match_operand 0 "gpc_reg_operand")//
> //       (ior (match_operand 0 
> "quarterword_offset21_memref_operand_or_indirect")//
> //            (match_operand 0 "immediate_operand"))))/
>
>
> and /gpc_reg_operand/ as:
>
> /(define_predicate "gpc_reg_operand"//
> //   (and (match_operand 0 "register_operand")//
> //        (match_test "(GET_CODE (op) != REG && GET_CODE(op) != SUBREG//
> //                      || (REGNO (op) >= ARG_POINTER_REGNUM//
> //                          && !CA_REGNO_P (REGNO (op)))//
> //                      || REGNO (op) == SFP_REGNO//
> //                      || REGNO (op) == ARG_POINTER_REGNUM//
> //                      || REGNO (op) <= MAX_REGFILE_REGNO)")))/
>
> Any of you any idea why the combine succeeds ?. I mean, it should fail 
> !. After combine, it does not match /movqi_internal/ pattern
> any more, but the compiler seems to think otherwise !.
>
> Best Regards,
>
> Henri.
>
>
>


  reply	other threads:[~2020-10-19 15:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19 12:53 Henri Cloetens
2020-10-19 15:55 ` Henri Cloetens [this message]
2020-10-19 19:28   ` Segher Boessenkool
2020-10-19 19:56     ` Henri Cloetens
2020-10-19 21:20       ` Segher Boessenkool
2020-10-20 13:19 ` Richard Earnshaw
2020-10-20 15:01   ` Henri Cloetens
2020-10-20 15:48     ` 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=2ade57f1-ff38-553c-0e06-1cbb445f5d4e@blueice.be \
    --to=henri.cloetens@blueice.be \
    --cc=gcc-help@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).