Bernd Schmidt <bschm...@redhat.com> writes: > On 11/25/2015 01:35 PM, Richard Sandiford wrote: >> The define_subst support made it syntactically possible to add >> attributes to a define_expand, but until now they had been ignored >> by genattrtab.c. This patch allows define_expands to have >> "code,alternative" attributes but raises an error for general >> "insn" attributes. > > This seems a little strange because define_expands don't really have > alternatives.
Yeah, but since an optab can be either a define_expand or a define_insn, we have to support the case where there could more than one alternative. For define_expands the alternative is always 0. This is in some ways like an asm or define_insn with no constraints, which also don't really have alternatives as such. We just treat them as having one alternative for consistency. There's already an explicit MAX in recog.c to force that. > Also, using a string like that rather than some kind of > identifier or a define_icode_attr maybe isn't the best approach? By "some kind of identifier" do you just mean replacing "code,alternative" with a string that doesn't have a comma? If so, I can do that, but what should the string be? The problem with define_icode_attr is that you get combinatorial explosion with the type of the return value. At the moment we just have integers and enums (which can be defined by define_enum_attr as well as define_attr), but who knows what we'll have in future? :-) Also, I didn't want to call them "icode" attributes because in future we might want attributes that really do depend only on the code, not on the alternative. Thanks, Richard
