On Tue, Oct 2, 2018 at 12:07 PM Eric Botcazou <ebotca...@adacore.com> wrote: > > > so the fix is to simply not optimize here? > > Yes, we cannot turn a BIT_FIELD_REF with rev-storage into a VIEW_CONVERT_EXPR. > > > Are there correctness issues with the patterns we have for rev-storage? But > > then some cases are let through via the realpart/imagpart/v_c_e case? I > > suppose we should never see REF_REVERSE_STORAGE_ORDER on refs operating on > > registers (SSA_NAMEs or even is_gimple_reg()s)? > > REF_REVERSE_STORAGE_ORDER is set on BIT_FIELD_REF and MEM_REF only.
OK. So I wonder why it is necessary to track 'reverse' in gimple_match_op at all given we bail out without optimizing as far as I can see? That is, isn't the gimple_simplify hunk, adjusted to check REF_REVERSE_STORAGE_ORDER instead of res_op->reverse, enough to fix the issue? > > Note that I think you need to adjust the GENERIC side as well, for example > > > > [...] > > > > where we lose the reverse-storage attribute as well. You'd probably > > have to cut out rev-storage refs somewhere in genmatch.c. > > I don't think that's necessary since we never fold top-level BIT_FIELD_REFs at > the GENERIC level so far. And given that it's impossible to control the top > level in match.pd, I'd rather not try something impossible unless rforced to > do it. This ought to be controlled directly from fold-const.c, if need be. OK, fine with me. Richard. > -- > Eric Botcazou
