public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/107617] New: SCC-VN with len_store and big endian
@ 2022-11-10 14:56 rdapp at gcc dot gnu.org
2022-11-10 14:57 ` [Bug middle-end/107617] " rdapp at gcc dot gnu.org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: rdapp at gcc dot gnu.org @ 2022-11-10 14:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
Bug ID: 107617
Summary: SCC-VN with len_store and big endian
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
CC: richard.guenther at gmail dot com
Target Milestone: ---
Target: s
Created attachment 53871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53871&action=edit
s390 patch for len_load/len_store
Hi,
Richard and I already quickly discussed this on the mailing list but I didn't
manage to progress analyzing as I was tied up with other things. Figured I
open a bug for tracking purposes and the possibility to maybe fix it in a later
stage.
I'm evaluating len_load/len_store support on s390 via the attached patch and
seeing a FAIL in
testsuite/gfortran.dg/power_3.f90
built with -march=z16 -O3 --param vect-partial-vector-usage=1
The problem seems to be that we evaluate a vector constant
{-1, 1, -1, 1} loaded with length 11 + 1(bias) = 12 as
{1, -1, 1} instead of {-1, 1, -1}.
Richard wrote on the mailing list:
> The error is probably in vn_reference_lookup_3 which assumes that
> 'len' applies to the vector elements in element order. See the part
> of the code where it checks for internal_store_fn_p. If 'len' is with
> respect to the memory and thus endianess has to be taken into
> account then for the IFN_LEN_STORE
>
> else if (fn == IFN_LEN_STORE)
> {
> pd.rhs_off = 0;
> pd.offset = offset2i;
> pd.size = (tree_to_uhwi (len)
> + -tree_to_shwi (bias)) * BITS_PER_UNIT;
> if (ranges_known_overlap_p (offset, maxsize,
> pd.offset, pd.size))
> return data->push_partial_def (pd, set, set,
> offseti, maxsizei);
>
> likely needs to adjust rhs_off from zero for big endian?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
@ 2022-11-10 14:57 ` rdapp at gcc dot gnu.org
2022-11-10 15:01 ` rdapp at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rdapp at gcc dot gnu.org @ 2022-11-10 14:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
rdapp at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
2022-11-10 14:57 ` [Bug middle-end/107617] " rdapp at gcc dot gnu.org
@ 2022-11-10 15:01 ` rdapp at gcc dot gnu.org
2022-11-11 7:42 ` [Bug tree-optimization/107617] " rguenth at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rdapp at gcc dot gnu.org @ 2022-11-10 15:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #1 from rdapp at gcc dot gnu.org ---
For completeness, the mailing list thread is here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602252.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
2022-11-10 14:57 ` [Bug middle-end/107617] " rdapp at gcc dot gnu.org
2022-11-10 15:01 ` rdapp at gcc dot gnu.org
@ 2022-11-11 7:42 ` rguenth at gcc dot gnu.org
2022-11-28 11:38 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-11 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org
Last reconfirmed| |2022-11-11
Component|middle-end |tree-optimization
Priority|P4 |P3
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be also reproducible on ppc64 big-endian? Or does that not have
len_store enabled?
Can you try reducing the fortran testcase or create a C testcase that has
the actual miscompilation separated in a function?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (2 preceding siblings ...)
2022-11-11 7:42 ` [Bug tree-optimization/107617] " rguenth at gcc dot gnu.org
@ 2022-11-28 11:38 ` rguenth at gcc dot gnu.org
2022-11-28 11:41 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-28 11:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I suppose it's the
+ MEM <vector(4) integer(kind=4)> [(integer(kind=4) *)_13] = { -1, 1, -1, 1 };
...
+ .LEN_STORE (vectp.75_247, 64B, 11, { 255, 255, 255, 255, 0, 0, 0, 1, 255,
255, 255, 255, 0, 0, 0, 1 }, -1);
..
+ MEM <vector(2) integer(kind=8)> [(integer(kind=8) *)&a] = { -1, 1 };
+ MEM <vector(2) integer(kind=8)> [(integer(kind=8) *)&a + 16B] = { -1, 1 };
+ a[4] = 1;
+ a[5] = -1;
+ a[6] = 1;
you are talking about where we elide the scalar loads from _13 stored into
a[].
A gimple testcase would be something like
typedef unsigned char v16qi __attribute__((vector_size(16)));
int a[4];
void __GIMPLE (ssa)
foo (void *p)
{
int v;
__BB(2):
.LEN_STORE (p_1(D), _Literal (int *) 64, 11, _Literal (v16qi) { _Literal
(unsigned char) 255, _Literal (unsigned char) 255, _Literal (unsigned char)
255, _Literal (unsigned char) 255, _Literal (unsigned char) 0, _Literal
(unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 1,
_Literal (unsigned char) 255, _Literal (unsigned char) 255, _Literal (unsigned
char) 255, _Literal (unsigned char) 255, _Literal (unsigned char) 0, _Literal
(unsigned char) 0, _Literal (unsigned char) 0, _Literal (unsigned char) 1 },
_Literal (signed char) -1);
v_2 = __MEM <int> ((int *)p_1(D));
v_3 = __MEM <int> ((int *)p_1(D) + 4);
v_4 = __MEM <int> ((int *)p_1(D) + 8);
v_5 = __MEM <int> ((int *)p_1(D) + 12);
a[0] = v_2;
a[1] = v_3;
a[2] = v_4;
a[3] = v_5;
return;
}
which produces
a[0] = 1;
a[1] = _Literal (int) -1;
a[2] = 1;
a[3] = v_5;
changing the len to 15 and thus folding the .LEN_STORE to a full store changes
that to
a[0] = _Literal (int) -1;
a[1] = 1;
a[2] = _Literal (int) -1;
a[3] = 1;
which I assume is correct? I think we'd need to feed a negative pd.rhs_off
into native_encode_expr but that's not supported there (and it treats -1
special).
Still .LEN_STORE covers bytes p + [0..11] here, correct? But the stored
value is interpreted wrongly here and the new rhs_off assumes little-endian
adjustment.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (3 preceding siblings ...)
2022-11-28 11:38 ` rguenth at gcc dot gnu.org
@ 2022-11-28 11:41 ` rguenth at gcc dot gnu.org
2022-12-11 13:36 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-11-28 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 53976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53976&action=edit
patch
Can you please test this patch? Visually inspecting the fortran testcase and
the GIMPLE testcase shows it fixes this case.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (4 preceding siblings ...)
2022-11-28 11:41 ` rguenth at gcc dot gnu.org
@ 2022-12-11 13:36 ` rguenth at gcc dot gnu.org
2022-12-13 6:25 ` rdapp at linux dot ibm.com
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-11 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ping - I'm waiting for you to confirm this fixes the issue.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (5 preceding siblings ...)
2022-12-11 13:36 ` rguenth at gcc dot gnu.org
@ 2022-12-13 6:25 ` rdapp at linux dot ibm.com
2022-12-13 14:48 ` rdapp at linux dot ibm.com
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rdapp at linux dot ibm.com @ 2022-12-13 6:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
rdapp at linux dot ibm.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdapp at linux dot ibm.com
--- Comment #6 from rdapp at linux dot ibm.com ---
Thank you and sorry for the delay, I was out on vacation. Will test it soon.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (6 preceding siblings ...)
2022-12-13 6:25 ` rdapp at linux dot ibm.com
@ 2022-12-13 14:48 ` rdapp at linux dot ibm.com
2022-12-14 7:48 ` cvs-commit at gcc dot gnu.org
2022-12-14 7:49 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rdapp at linux dot ibm.com @ 2022-12-13 14:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #7 from rdapp at linux dot ibm.com ---
The patch fixes the problem for me. I did a full bootstrap with enabled
len_load support. No new regressions with -march=arch14. Thanks again!
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (7 preceding siblings ...)
2022-12-13 14:48 ` rdapp at linux dot ibm.com
@ 2022-12-14 7:48 ` cvs-commit at gcc dot gnu.org
2022-12-14 7:49 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-12-14 7:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:d3fee43fb3873b00de913e0501fbf28b56d2ce64
commit r13-4694-gd3fee43fb3873b00de913e0501fbf28b56d2ce64
Author: Richard Biener <rguenther@suse.de>
Date: Mon Nov 28 12:38:46 2022 +0100
tree-optimization/107617 - big-endian .LEN_STORE VN
The following fixes a mistake in interpreting .LEN_STORE definitions
during value-numbering when in big-endian mode. We cannot offset
the encoding of the RHS but instead encode to an offsetted position
which is then treated correctly by the endian aware copying code.
PR tree-optimization/107617
* tree-ssa-sccvn.cc (vn_walk_cb_data::push_partial_def):
Handle negative pd.rhs_off.
(vn_reference_lookup_3): Properly provide pd.rhs_off
for .LEN_STORE on big-endian targets.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug tree-optimization/107617] SCC-VN with len_store and big endian
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
` (8 preceding siblings ...)
2022-12-14 7:48 ` cvs-commit at gcc dot gnu.org
@ 2022-12-14 7:49 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-12-14 7:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107617
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-12-14 7:49 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-10 14:56 [Bug middle-end/107617] New: SCC-VN with len_store and big endian rdapp at gcc dot gnu.org
2022-11-10 14:57 ` [Bug middle-end/107617] " rdapp at gcc dot gnu.org
2022-11-10 15:01 ` rdapp at gcc dot gnu.org
2022-11-11 7:42 ` [Bug tree-optimization/107617] " rguenth at gcc dot gnu.org
2022-11-28 11:38 ` rguenth at gcc dot gnu.org
2022-11-28 11:41 ` rguenth at gcc dot gnu.org
2022-12-11 13:36 ` rguenth at gcc dot gnu.org
2022-12-13 6:25 ` rdapp at linux dot ibm.com
2022-12-13 14:48 ` rdapp at linux dot ibm.com
2022-12-14 7:48 ` cvs-commit at gcc dot gnu.org
2022-12-14 7:49 ` rguenth at gcc dot gnu.org
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).