This time instead of having a NOP copy insn that we can completely ignore and
ultimately remove, we have a NOP set within a multi-set PARALLEL.  It triggers,
the same failure when the source of such a set is a hard register for the same
reasons as we've already noted in the BZ and patches-to-date.

For prior cases we've been able to mark the insn as a nop set and ignore it for
the rest of cse_insn, ultimately removing it.  That's not really an option here
as there are other sets that we have to preserve.

We might be able to fix this instance by splitting the multi-set insn, but I'm
not keen to introduce splitting into cse.  Furthermore, the target may not be
able to split the insn.  So I considered this is non-starter.

What I finally settled on was to use the existing do_not_record machinery to
ignore the nop set within the parallel (and only that set within the parallel).

One might argue that we should always ignore a REG_UNUSED set.  But I rejected
that idea -- we could have cse-able divmod insns where the first had a
REG_UNUSED note for a destination, but the second did not.

One might also argue that we could have a nop set without a REG_UNUSED in a
multi-set parallel and thus we could trigger yet another insert_regs ICE at
some point.  I tend to think this is a possibility.  If we see this happen,
we'll have to revisit.

	PR rtl-optimization/90275
	* cse.c (cse_insn): Avoid recording nop sets in multi-set parallels
	when the destination has a REG_UNUSED note.