On Sat, Jan 24, 2015 at 3:29 AM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > 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.
Areg, can we run some benchmarks? -- H.J.
