Re: [PATCH] Change EQ_ATTR_ALT to support up to 64 alternatives

[Richard Sandiford <richard.sandiford@arm.com>]

Ilya Leoshkevich <iii@linux.ibm.com> writes:
> On S/390 there is a need to support more than 32 instruction
> alternatives per define_insn.  Currently this is not explicitly
> prohibited or unsupported: MAX_RECOG_ALTERNATIVES is equal 35, and,
> futhermore, the related code uses uint64_t for bitmaps in most places.
>
> However, genattrtab contains the logic to convert (eq_attr "attribute"
> "value") RTXs to (eq_attr_alt bitmap) RTXs, where bitmap contains
> alternatives, whose "attribute" has the corresponding "value".
> Unfortunately, bitmap is only 32 bits.
>
> When adding the 33rd alternative, this led to (eq_attr "type" "larl")
> becoming (eq_attr_alt -1050625 1), where -1050625 == 0xffeff7ff.  The
> cleared bits 12, 21 and 32 correspond to two existing and one newly
> added insn of type "larl".  compute_alternative_mask sign extended this
> to 0xffffffffffeff7ff, which contained non-existent alternatives, and
> this made simplify_test_exp fail with "invalid alternative specified".
>
> I'm not sure why it didn't fail the same way before, since the top bit,
> which led to sign extension, should have been set even with 32
> alternatives.  Maybe simplify_test_exp was not called for "type"
> attribute for some reason?
>
> This patch widens EQ_ATTR_ALT bitmap to 64 bits, making it possible to
> gracefully handle up to 64 alternatives.  It eliminates the problem with
> the 33rd alternative on S/390.

Could you test this with --enable-checking=yes,rtl , if you haven't already,
to check that there are no mossing XINT->XWINT changes?

OK if that passes, thanks.

Richard