> 2018-09-28 Eric Botcazou
>
> PR tree-optimization/86659
> * gimple-match.h (struct gimple_match_op): Add reverse field.
Jonathan privately remarked that the new member should probably be initialized
in the constructors (thanks!). Done thusly, applied on mainline as obvious.
On Fri, Oct 5, 2018 at 10:29 AM Eric Botcazou wrote:
>
> > 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?
>
> Because of the valueization? If it is done, gimple_simplify returns true so
> the result will b
> 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?
Because of the valueization? If it is done, gimple_simplify returns true so
the result will be synthetized from res_op by means of maybe_build_generic_op.
Th
On Tue, Oct 2, 2018 at 12:07 PM Eric Botcazou 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 th
> 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
On Fri, Sep 28, 2018 at 7:01 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression introduced by the canonicalization of BIT_FIELD_REF in
> match.pd, which totally disregards the REF_REVERSE_STORAGE_ORDER flag, and
> visible as the failure of gnat.dg/sso/q[23].adb on SPARC 64-bit. But the
> un
