On Tue, Sep 21, 2021 at 08:24:04AM +0200, Richard Biener wrote: > On Tue, Sep 21, 2021 at 6:18 AM Jeff Law via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > If we were catching the scenario which led to the creation of (subreg > > (truncate)) in combine and instead of creating (subreg (truncate)) we > > instead created the simplified, correct form would that ease your concerns? > > Sorry to chime in,
No, please do! > but if (subreg (truncate ...)) is invalid it would be OK for > simplify_gen_subreg () to > 1) return NULL_RTX Yes, that is valid, but the simplify-rtx routines (as well as pretty much everything dealing with RTL) doesn't have to check it is valid RTL, as a matter of principle: it can just assume anything passed around *is* valid. Anything simplify-rtx gets as input should be valid RTL, and the only thing it should be concerned with is *generating* only valid RTL as well :-) > 2) return valid RTX, in this case the suggested canoncalized form > I agree that simplify_gen_subreg should not return (subreg (truncate ..)). > > So I'm not understanding if you are suggesting that even calling > simplify_gen_subreg on a (truncate ...) is invalid? What would the semantics be? A subreg has a reg as operand, and its semantics are different for pseudos and for hard regs! We could define the semantics of calling simplify_gen_subreg on non-regs, but that will make the interface only more confused imo, much harder to use correctly. > Now, the patch changes simplify_subreg where it's not clear whether > the subreg already exists (it should not) or whether we are about to > construct it, seeing if there's a valid RTX that expresses the semantic > as if the op were pushed to a pseudo (aka we're combining on the fly). > > It's a bit like fold_convert (double_type_node, integer_one_node) > second-guessing and doing a FLOAT_EXPR when folding > the implicit CONVERT_EXPR. Yeah :-/ Segher
