Fix value numbering dealing with reverse byte order
authorAndrew Pinski <apinski@marvell.com>
Thu, 16 Jan 2020 07:54:51 +0000 (07:54 +0000)
committerAndrew Pinski <apinski@marvell.com>
Thu, 16 Jan 2020 12:34:32 +0000 (12:34 +0000)
commit2db99ef7896914bfbca1adc40f6ac4ba8887f040
tree80b5d90546ab599c47967b969c77574cba2ea581
parent7c6056d52ef7ea43b503b11a571b316d55f392c7
Fix value numbering dealing with reverse byte order

Hi,
  While working on bit-field lowering pass, I came across this bug.
The IR looks like:
  VIEW_CONVERT_EXPR<unsigned long>(var1) = _12;
  _1 = BIT_FIELD_REF <var1, 64, 0>;

Where the BIT_FIELD_REF has REF_REVERSE_STORAGE_ORDER set on it
and var1's type has TYPE_REVERSE_STORAGE_ORDER set on it.
PRE/FRE would decided to prop _12 into the BFR statement
which would produce wrong code.
And yes _12 has the correct byte order already; bit-field lowering
removes the implicit byte swaps in the IR and adds the explicity
to make it easier optimize later on.

This patch adds a check for storage_order_barrier_p on the lhs tree
which returns true in the case where we had a reverse order with a VCE.

ChangeLog:
* tree-ssa-sccvn.c(vn_reference_lookup_3): Check lhs for
!storage_order_barrier_p.
gcc/ChangeLog
gcc/tree-ssa-sccvn.c