Hi Richard,
On Fri, Jul 05, 2019 at 04:20:37PM +0100, Richard Sandiford wrote:
> This patch is part of a series that fixes ambiguous attribute
> uses in .md files, i.e. cases in which attributes didn't use
> <ITER:ATTR> to specify an iterator, and in which <ATTR> could
> have different values depending on the iterator chosen.
I have sometimes wondered which iterator is chosen in ambiguous cases.
So I finally looked it up, and the doc says
The @code{@var{iterator}:} prefix may be omitted, in which case the
substitution will be attempted for every iterator expansion.
Well ugh :-) I always thought there was some rule, but nope.
Maybe there should be some way of indicating what iterator you want if
none is mentioned? For the whole pattern, or some global priority scheme
even? Changes like (random example)
> -(define_insn "*mov<mode>_update2"
> +(define_insn "*mov<SFDF:mode>_update2"
> [(set (mem:SFDF (plus:P (match_operand:P 1 "gpc_reg_operand" "0,0")
> (match_operand:P 2 "reg_or_short_operand" "r,I")))
> - (match_operand:SFDF 3 "gpc_reg_operand" "<Ff>,<Ff>"))
> + (match_operand:SFDF 3 "gpc_reg_operand" "<SFDF:Ff>,<SFDF:Ff>"))
> (set (match_operand:P 0 "gpc_reg_operand" "=b,b")
> (plus:P (match_dup 1) (match_dup 2)))]
> "TARGET_HARD_FLOAT && TARGET_UPDATE
> - && (!avoiding_indexed_address_p (<MODE>mode)
> + && (!avoiding_indexed_address_p (<SFDF:MODE>mode)
do not make the code more readable. A rule like "Do not use P if any
other mode iterator is available" would work for us.
(The patch is fine if the whole series is approved, of course).
Thanks,
Segher
