* [PATCH] Fix value numbering dealing with reverse byte order
@ 2020-01-16 8:55 apinski
2020-01-16 9:37 ` Richard Biener
0 siblings, 1 reply; 2+ messages in thread
From: apinski @ 2020-01-16 8:55 UTC (permalink / raw)
To: gcc-patches; +Cc: Andrew Pinski
From: Andrew Pinski <apinski@marvell.com>
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.
gcc.c-torture/execute/pr86659-1.c was the testcase which showed the issue.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regression.
Thanks,
Andrew Pinski
ChangeLog:
* tree-ssa-sccvn.c(vn_reference_lookup_3): Check lhs for
!storage_order_barrier_p.
Change-Id: I7810de6fc4ff01e431033fa7f7f7b3ec95f67644
---
gcc/tree-ssa-sccvn.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 3b27c50..4d13015 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2593,6 +2593,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void *data_,
&offset2, &size2, &maxsize2, &reverse);
if (base2
&& !reverse
+ && !storage_order_barrier_p (lhs)
&& known_eq (maxsize2, size2)
&& multiple_p (size2, BITS_PER_UNIT)
&& multiple_p (offset2, BITS_PER_UNIT)
@@ -2695,6 +2696,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void *data_,
&offset2, &size2, &maxsize2, &reverse);
tree def_rhs = gimple_assign_rhs1 (def_stmt);
if (!reverse
+ && !storage_order_barrier_p (lhs)
&& known_size_p (maxsize2)
&& known_eq (maxsize2, size2)
&& adjust_offsets_for_equal_base_address (base, &offset,
--
1.8.3.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Fix value numbering dealing with reverse byte order
2020-01-16 8:55 [PATCH] Fix value numbering dealing with reverse byte order apinski
@ 2020-01-16 9:37 ` Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2020-01-16 9:37 UTC (permalink / raw)
To: gcc-patches, apinski; +Cc: Andrew Pinski
On January 16, 2020 9:13:46 AM GMT+01:00, apinski@marvell.com wrote:
>From: Andrew Pinski <apinski@marvell.com>
>
>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.
>
>gcc.c-torture/execute/pr86659-1.c was the testcase which showed the
>issue.
>
>OK? Bootstrapped and tested on x86_64-linux-gnu with no regression.
OK.
Richard.
>Thanks,
>Andrew Pinski
>
>ChangeLog:
>* tree-ssa-sccvn.c(vn_reference_lookup_3): Check lhs for
>!storage_order_barrier_p.
>
>Change-Id: I7810de6fc4ff01e431033fa7f7f7b3ec95f67644
>---
> gcc/tree-ssa-sccvn.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
>index 3b27c50..4d13015 100644
>--- a/gcc/tree-ssa-sccvn.c
>+++ b/gcc/tree-ssa-sccvn.c
>@@ -2593,6 +2593,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse,
>void *data_,
> &offset2, &size2, &maxsize2, &reverse);
> if (base2
> && !reverse
>+ && !storage_order_barrier_p (lhs)
> && known_eq (maxsize2, size2)
> && multiple_p (size2, BITS_PER_UNIT)
> && multiple_p (offset2, BITS_PER_UNIT)
>@@ -2695,6 +2696,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse,
>void *data_,
> &offset2, &size2, &maxsize2, &reverse);
> tree def_rhs = gimple_assign_rhs1 (def_stmt);
> if (!reverse
>+ && !storage_order_barrier_p (lhs)
> && known_size_p (maxsize2)
> && known_eq (maxsize2, size2)
> && adjust_offsets_for_equal_base_address (base, &offset,
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-01-16 8:54 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-16 8:55 [PATCH] Fix value numbering dealing with reverse byte order apinski
2020-01-16 9:37 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).