Hi Ian, > I'm sorry I haven't had time to reply to this patch, but I'm not > entirely happy with it. Conceptually it seems reasonable, but I don't > understand why your implementation has to work the way it does; it > seems overly complicated. And I wonder whether it wouldn't be simpler > to achieve the same effect using constraints.
the recog, reload and back end changes are straightforward and probably not what you considered overly complex. The lengthy part is necessary to have attribute getter functions which allow to specify the alternative as additional parameter. I admit that these are a lot of quite mechanical changes to the genattr stuff but my hope was that these getter functions might be useful in other contexts as well. The genattr changes allow me to use the existing attribute mechanism. An alternative would be to enhance the language of the machine description files. If we do this we might add the enabled flag to the insn_data struct as it is done with the constraint letters. But this would probably need even more code. And since we already have per alternative attributes I think we don't need a new mechanism to describe this. Misusing the constraint letters to enable or disable alternatives is a solution which is already used by back ends. On S/390 we have the 'O' constraint familiy which only returns true for machines providing the extended immediate facility. But actually this was one of the reasons why I wanted to change this. I think this is a non-obvious mixture of different concepts. The constraint letters should only depend on the type of the operand. Adding additional conditions to it could create a real mess. Besides the presence of the extended immediate facility the S/390 'O' constraint just checks for immediate values of different bit widths. For immediate values on other machines I therefore have to duplicate these constraints which is quite ugly and might be a problem since constraint letters are already quite sparse. Since a single insn alternative usually has more than just one operand there are several constraint letters which might be used to disable that alternative. The availability of a certain insn alternative mostly means that the instruction is not available. But how can this be coupled to the validity of an operand for an insn? Either the instruction isn't available then *ALL* operands of the alternative are invalid or if it is available *ALL* operands of the appropriate type are valid. I don't think it is a clean concept having one operand of an alternative accepted but the other rejected since the instruction is not present. Bye, -Andreas-
