Analysis of high priority PR c/2454

[Joe Buck]

I wrote:
> > It seems that there are three possible semantics: the extra bits are
> > either don't care (or unknown), sign-extended, or zero-extended.  What if
> > these three cases were made explicit (by, say, adding an attribute)?
> > Optimizations that don't care about the bits could just ignore this
> > attribute; optimizations that do care would have to check it.
> > But doing it that way might minimize the number of changes needed for
> > robust operation.

Roger Sayle wrote:
> A even simpler form of the above, would be to force all MD files to
> contain zero extension and sign extension patterns.  This allows
> subreg to always mean undefined extra bits, and avoids having to
> interpret pairs of shift operations as zero or sign extension.
> The backend then has the opportunity to use either shift pairs or
> LOAD_EXTEND_OP functionality to implement the required operation.

> You'll notice that those backends that define zero and sign extension
> insns, are unaffected by PR c/2454.

If this fixes the bugs, great, at least as a first step.  Speed is
worthless if it produces wrong results.

But wouldn't such a solution pessimize code in some cases?  If we know,
because of the way that the subreg was generated, that it already exists
in zero-extended or sign-extended form (e.g. because a byte read from
memory on the processor always generates such a form in the register),
then requiring the compiler to generate an explicit zero-extend or sign
extend would be wasted computation.