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).