Hi, > The x86 pattern is called "anddi_1_rex64", which is not one of the standard > names: that means the compiler will never emit it directly. Not necessarily. Someone simply could call gen_andidi_1_rex64 (e.g. from i386.c) to emit this pattern. That the insn doesn't use a standard name only means that it is never generated from the optab rtl expander this way.
> The only RTL that > matches that pattern will be that which has already been matched by the x86's > "anddi3" expander, which will have called ix86_expand_binary_operator to munge > the operands into a form that the "anddi_1_rex64" pattern can accept without > problems. An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" expander. Potentially a completely AND unrelated expander could have been used and the optimization steps could have transformed it into an AND rtx which is then matched by anddi_1_rex64. Of course the insn definitions better should cover everything emittable by the expanders otherwise you get an ICE. > In your case, you're defining the named pattern "anddi3" directly as an > insn, and the compiler is going to assume it's fully capable of dealing with > whatever combination of operands are accepted by the calls to > nonimmediate_operand and general_operand. (I don't think that prefixing > "anddi3" with an asterisk will hide it from the compiler and prevent it being > treated as the named pattern for anddi3; IIRC that doesn't work to protect the > well-known names, and so neither can you have, for example, two patterns > called "anddi3" and "*anddi3"). Look in the gcc internals manual for the semantics of the asterisk: "For the purpose of debugging the compiler, you may also specify a name beginning with the `*' character. Such a name is used only for identifying the instruction in RTL dumps; it is entirely equivalent to having a nameless pattern for all other purposes." Our "*anddi3" pattern can't be emitted "directly" since it begins with an asterisk. For insn definitions starting with an asterisk gcc does not even generate a gen_... function. If optabs calls gen_anddi3 of course our expander is used which takes care of generating the correct insn. > You are confusing the *condition* with the *constraints*. Your conditions > are "nonimmediate_operand", which accept pretty much anything. It is only the > conditions that are tested in recog, not the constraints. I don't think so and I am aware that only reload considers contraints worth looking at. The chapter I've cited from the gcc internals manual describes insn conditions which are pretty much the things we are arguing about. The "nonimmediate_operand" is neither a constraint nor a condition it's a predicate. > Also, you may have confused gcc by creating a pattern with the same name as > a well-known named pattern but trying to make it nameless with using an > asterisk. Don't try to re-use the well-known pattern names; do something > quite different, such as adding a suffix like the x86 does. As I've described above adding an asterisk is the standard way of providing a pattern name which only appears in the rtl dumps and does not have any other function than this. Since gcc handles such patterns exactly like nameless patterns this is certainly not the source of confusion for gcc. > If you need to > impose conditions on your operands that the condition tests can't handle, then > in the body of an expander is the place to do it. As I said we have an anddi3 expanders which does perfectly the right thing (at least there are no know bugs) will say it doesn't create insns which can't be matched by a define_insn. > > If there is no other way than splitting the pattern I'll do this. > > I'm really very sure this is the way to go. It works for the x86, after > all! So, I would reckon your approach is > > 1) define expanders for the insns Again we have an expander in place. > 2) rename the 'nameless' patterns so that you can call emit/gen_XXX from your > expander and not get into an infinite recursion! As described the patterns are in fact nameless and I see the danger of having an infinite recursion. > > Probably > > somebody then should have a look at the i386 machine description and maybe > > it should be made a bit clearer in the gcc internals manual. As I've pointed out I still think that the i386 back end uses the same trick as we do and if we have to fix something somebody should check whether the i386 could run into the same problems. Bye, -Andreas-
