[ Please don't top-post ]
Hi Henri,
On Mon, Oct 19, 2020 at 05:55:55PM +0200, Henri Cloetens wrote:
> On 10/19/2020 02:53 PM, Henri Cloetens wrote:
[ snip ]
> >This, of course, is not correct any more. Now, how should I prevent
> >this ?, the pattern is defined in the .md-file as:
The combiner only ever does transformations that result in recognised
instructions, see this code (and many lines before):
/* If it still isn't recognized, fail and change things back the way they
were. */
if ((insn_code_number < 0
/* Is the result a reasonable ASM_OPERANDS? */
&& (! check_asm_operands (newpat) || added_sets_1 || added_sets_2)))
{
undo_all ();
return 0;
}
> >/(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"))))/
What is quarterword_offset21_memref_operand_or_indirect defined as?
> >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 !.
Maybe it matches some other pattern? Use -fdump-rtl-combine-all and
then look at the RTL dump file: at the end of each function it shows the
resulting RTL stream, and each insn like
(insn 7 18 8 2 (set (reg:DI 3 3)
(plus:DI (reg/f:DI 111 sfp)
(const_int 112 [0x70]))) "vlf.c":18:10 69 {*adddi3}
(nil))
shows the name of the pattern that matched this (*adddi3 here).
> 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.)
Before you said that bad code was generated, and now you say the
compiler crashes. Which is it?
> It seems to me this "illegal" mode is the result of the /combine/ step,
> trying to "improve" by doing combinations of
> instructions "at random".
Combine combines instructions that have a (register) dependency. What
it comes up with as the combined insn is often not something that the
target in fact supports, but that is fine: then that combination is not
made.
> Here, it tries a "combination" that does not
> make sense, but it causes a crash in
> the abovementioned routine.
Please open a bug report (see <https://gcc.gnu.org/bugs.html> for
instructions). Thanks in advance!
> 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.
Btw, those numbers vary over time, and they are different for different
targets (combine currently is 265 for x86_64, and 270 for rs6000). Just
use the name please :-)
Segher
