On Tue, Feb 28, 2017 at 04:43:19PM +0100, Richard Biener wrote: > > This patch just attempts to reuse as much as possible from orig_inner and > > only use adjusted BIT_FIELD_REF on that when in GENERIC (first I've tried to > > use instead COMPONENT_REF with DECL_BIT_FIELD_REPRESENTATIVE, but that isn't > > handled by constexpr.c either). > > Bootstrapped/regtested on x86_64/i686-linux, ok for trunk? > > Hmm, I'd rather not do anything is_gimple_form specific.
I think doing what the patch for TREE_CODE (orig_inner) == COMPONENT_REF is probably fine as well, at least assuming say SCCVN uses get_inner_reference or something similar to query to ultimate bases and offsets for CSE purposes. Though, for non-bitfield refs we still use in various places x.foo.bar.baz and in other places MEM_REF[&x + xyz], so I think SCCVN needs to deal with those already anyway. > Can't we > restrict this transform to work on the outermost handled-component only? That is essentially what the patch does; get_inner_reference returns the ultimate base and the patch re-adds the handled-components other than the outermost one back if it yields the same positions/sizes. Perhaps an alternative would be not to call get_inner_reference at all, just something that does handle only the outermost handled component (or add get_inner_reference argument to do that). > Ideally we'd want to find a common base of course. > > The folding is also guarded with optimize != 0 so maybe simply disable > it from the FEs? (but yes, you say it does a bad job on GIMPLE No, I'm afraid we wouldn't fold it at all then. > which is quite understandable as there's no TRUTH_*, but we can > eventually call it from gimplification instead?) The optimize_bit_field_compare perhaps can work in some cases on GIMPLE, the truth_fold_andor* I think would need something like tree-ssa-reassoc.c infrastructure or something similar to gather many comparisons from multiple basic blocks. Jakub