Yeah. I expect in practice most people who used "?" and "!" attached
them to a particular operand for a reason. From a quick scan through
386.exp it looked like almost all uses would either want this behaviour
or wouldn't care. An interesting exception is:
(define_insn "extendsidi2_1"
[(set (match_operand:DI 0 "nonimmediate_operand" "=*A,r,?r,?*o")
(sign_extend:DI (match_operand:SI 1 "register_operand" "0,0,r,r")))
(clobber (reg:CC FLAGS_REG))
(clobber (match_scratch:SI 2 "=X,X,X,&r"))]
"!TARGET_64BIT"
"#")
I don't know how effective the third alternative is with LRA. Surely
a "r<-0" alternative is by definition a case where "r<-r" is possible
only with a "?"-cost reload? Seems to me we could just delete it.
But assuming it does some good, I suppose the "?" really does apply to
the alternative as a whole. If we had to reload operand 1 or operand 0,
there's an extra cost if it can't use the same register as the other
operand.
Wouldn't it be better to make "?" and "!" behave the new way and only
add new constraints if it turns out that the old behaviour really is
useful in some cases?
Maybe stage 4 isn't the time to be making that kind of change.
Still, it'd be great if someone who's set up do x86_64 benchmarking
could measure the effect of making "?" and "!" behave like the
new constraints.