On Wed, Jun 12, 2019 at 06:08:13AM +0300, Dimitar Dimitrov wrote: > On неделя, 9 юни 2019 г. 17:38:58 EEST Segher Boessenkool wrote: > > On Sun, Jun 09, 2019 at 11:01:38PM +0300, Dimitar Dimitrov wrote: > > > +; An unfortunate side effect is that quite a few invalid RTL patterns are > > > +; generated. For example: > > > +; ... (zero_extend:SI (match_operand:SI ...)) ... > > > > You could perhaps use a mode iterator like rs6000's EXTHI and friends. > The machine description already extensively uses mode iterators.
I meant specifically type iterators like this. We can write e.g. (zero_extend:EXTSI (match_operand:SI ...)) and it will only generate patterns for those modes that SI can be extended to. This might be hard to make work with more than one mode in your pattern though :-( > > > +(define_subst "alu2_zext_subst" > > > + [(set (match_operand:EQD 0 "" "") > > > + (ALUOP2:EQD (zero_extend:EQD (match_operand:EQD 1 "" ""))))] > > > > I don't know if this actually works for define_subst, but at least in many > > other cases you can write this like > > > > (define_subst "alu2_zext_subst" > > [(set (match_operand:EQD 0) > > (ALUOP2:EQD (zero_extend:EQD (match_operand:EQD 1))))] > > > > (you can omit trailing empty string arguments). > Indeed, genmddump generates the same output with or without the empty > strings. > I was not sure which is the preferred form, though. I see lots of MD > definitions in the GCC tree with empty strings. Yes, this is a pretty new feature :-) Usually all those trailing "" are just noise. Sometimes there *could* be something non-empty there, and then you sometimes want to keep it, as documentation or whatever. > > > +; There is no pipeline, so our scheduling description is simple. > > > +(define_automaton "pru") > > > +(define_cpu_unit "cpu" "pru") > > > + > > > +(define_insn_reservation "everything" 1 (match_test "true") "cpu") > > > > Because you have a scheduling description, INSN_SCHEDULING is defined, > > and that makes combine not create SUBREGs of MEM. Which is pretty > > important :-) > Would lack of INSN_SCHEDULING result in a more efficient target code? Is it > recommended? I added dummy scheduling as a precaution to avoid issues like > PR78883 for AVR. SUBREGs of MEM are an obsolete feature. Maybe we should decouple it from INSN_SCHEDULING; as it is now this workaround is non-obvious and frankly a bit silly. I'll see what I can do. Segher
