https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Andreas Krebbel from comment #22)
> The longer a have been looking at these STRICT_LOW_PART issue the more I
> think that STRICT_LOW_PART is an awful way to express what we need:
>
> - the information needed to understand what it is doing is distributed
> across 3 RTXs (strict_low_part (subreg:mode1 (reg:mode2 xx) OFS))
> - the big problems arise since the involved RTXs are separately optimized
> and we might end up with partial information without a clear definition of
> how to deal with that
> - actually it is really hard to handle the RTXs as one unit. Recursively
> walking RTXs needs to record whether we are in a STRICT_LOW_PART or not.
>
>
> I think it might make sense to explore other ways to express this:
>
> 1. SUBREG flag - Looks easy, but it would be hard to catch all places which
> should care about that flag.
>
> 2. Introduce a new RTX code which has a mode and an offset attached but does
> not require an additional SUBREG anymore.
>
> 3. Since a STRICT_LOW_PART is essentially a bit insertion operation we could
> express it always with a ZERO_EXTRACT target operand and get rid of
> STRICT_LOW_PART entirely. A ZERO_EXTRACT would be somewhat more cumbersome
> to deal with, since it would always require to check the bit width and
> offset for all the cases which just use mode boundaries. But at least most
> passes know how to deal with them already.
4. With existing simple RTL:
(set (reg:DI x) (ior:DI (and:DI (reg:DI x) (const_int -4294967296))
(zero_extend:DI (reg:SI y))))
(ZERO_EXTRACT is never useful IMNSHO: it just makes the easy cases slightly
easier to write, and causes a lot of useless work everywhere else).
