Jeff Law <l...@redhat.com> writes:
> On 01/14/15 16:52, Vladimir Makarov wrote:
>> The problem of unexpected code generation is discussed on
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64110
>>
>> The following patch introduces 2 new constraints '^' and '$' which
>> are analogous to '?' and '!' but disfavor given alternative when *the
>> operand with the new constraint* needs a reload ('?' and '!' disfavor
>> the alternative if *any* operand needs a reload). I hope the new
>> constraints will be useful for other insns and targets.
> Right. This gives us finer grained control over when to disparage an
> alternative.
>
> Reloading some of the operands in an alternative may not be a big deal,
> but there may be other operands in the alternative that if a reload was
> needed for that operand would be so bad that we'd want to reject the
> entire alternative.
>
> The example I had in mind when I read Vlad's analysis in the BZ were the
> old movb and addb patterns on the PA. Basically we have some side
> effect like addition/subtraction/register copy along with a conditional
> jump.
>
> (define_insn ""
> [(set (pc)
> (if_then_else
> (match_operator 2 "movb_comparison_operator"
> [(match_operand:SI 1 "register_operand" "r,r,r,r")
> (const_int 0)])
> (label_ref (match_operand 3 "" ""))
> (pc)))
> (set (match_operand:SI 0 "reg_before_reload_operand" "=!r,!*f,*Q,!*q")
> (match_dup 1))]
>
> Needing a reload for operand 1 really isn't a big deal here, but
> reloading operand 0 is a disaster. This would be a good place to use
> the new constraint modifiers.
>
> I can distinctly recall running into similar issues on other ports
> through the years. I wouldn't be at all surprised if a notable
> percentage of the "!" and "?"s that appear in our machine descriptions
> would be better off as "^" and "$".
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.
Thanks,
Richard
