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.
>
>
>
next prev parent 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).