Re: [PATCH] Fix ICE in match_asm_constraints_1 (PR inline-asm/84941)

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 19 Mar 2018, Jakub Jelinek wrote:

> The inline-asm here has "1p" constraint and we end up with
> (plus (frame) (const_int ...))

Blaeh.  Note that "1p" is actually invalid:

--------------
`0', `1', `2', ... `9'
     An operand that matches the specified operand number is allowed.
     If a digit is used together with letters within the same
     alternative, the digit should come last.
--------------

Changing the order to "p1" would disable the transformation as well, 
because match_asm_constraints_1() uses strtoul on the constraint start.

But let's say we don't want to go there and reject this form for good 
(though I think we should), so ...

> as input; even when the matching output is a REG, I'm not really
> sure emit_move_insn can handle arbitrary expressions (consider e.g.
> "1X" constraint), and calling reg_overlap_mentioned_p on something other
> than REG/SUBREG/MEM/constant (and a couple of selected other cases)
> will ICE too.  My understanding is that the match_asm_constraints mini-pass
> is an optimization, so we can try to handle cases which make sense, but if
> there is something too difficult to handle we can just punt and let reload
> do its job or error_for_asm if it can't reload it.  Especially when I
> believe such input expressions can be there only when the numeric constraint
> is mixed with some other one, otherwise it should have been a REG or MEM
> or something similar.

... this makes sense.  But I think you're too generous in supporting 
strange inputs:

>        if (! REG_P (output)
>  	  || rtx_equal_p (output, input)
>  	  || (GET_MODE (input) != VOIDmode
> -	      && GET_MODE (input) != GET_MODE (output)))
> +	      && GET_MODE (input) != GET_MODE (output))
> +	  || !(REG_P (input) || SUBREG_P (input)
> +	       || MEM_P (input) || CONSTANT_P (input)))

I'd only allow REG_P (input) as well, not any of the other forms.


Ciao,
Michael.