public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/96281] New: TBAA does not work as expected for a simple test case
@ 2020-07-22 9:07 felix.yang at huawei dot com
2020-07-22 14:24 ` [Bug middle-end/96281] " rguenth at gcc dot gnu.org
2021-12-22 10:20 ` [Bug tree-optimization/96281] " pinskia at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: felix.yang at huawei dot com @ 2020-07-22 9:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96281
Bug ID: 96281
Summary: TBAA does not work as expected for a simple test case
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: alias
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.yang at huawei dot com
Target Milestone: ---
Target: aarch64
Test case: foo.c
typedef struct state_t {
int threadid;
} state_t;
int history_h[8][12][64];
void history_good (state_t *s) {
int i, j;
if (s->threadid >= 0 && s->threadid < 8) {
for (i = 0; i < 12; i++) {
for (j = 0; j < 64; j++) {
history_h[s->threadid][i][j] = (history_h[s->threadid][i][j] +
1) >> 1;
}
}
}
}
$ gcc -S -O2 -ftree-loop-vectorize -funroll-loops foo.c -fopt-info
foo.c:14:13: optimized: loop unrolled 6 times
When the input parameter s is specified to be unaliased with __restrict__ type
qualifier like:
void history_good (state_t * __restrict__ s)
The inner loop could be auto-vectorized:
$ gcc -S -O2 -ftree-loop-vectorize -funroll-loops foo.c -fopt-info
foo.c:14:13: optimized: loop vectorized using 16 byte vectors
foo.c:8:6: optimized: loop with 15 iterations completely unrolled (header
execution count 16535624)
Looks like TBAA is not working here for this case. Then I noticed the
following logic in tree-ssa-alias.c:
1939 /* When we are trying to disambiguate an access with a pointer
dereference
1940 as base versus one with a decl as base we can use both the size
1941 of the decl and its dynamic type for extra disambiguation.
1942 ??? We do not know anything about the dynamic type of the decl
1943 other than that its alias-set contains base2_alias_set as a subset
1944 which does not help us here. */
1945 /* As we know nothing useful about the dynamic type of the decl just
1946 use the usual conflict check rather than a subset test.
1947 ??? We could introduce -fvery-strict-aliasing when the language
1948 does not allow decls to have a dynamic type that differs from their
1949 static type. Then we can check
1950 !alias_set_subset_of (base1_alias_set, base2_alias_set) instead. */
1951 if (base1_alias_set != base2_alias_set
1952 && !alias_sets_conflict_p (base1_alias_set, base2_alias_set))
1953 return false;
This was introduced by: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42834
>From the comments, this depends on the language of the source code.
So at least for C & C++, could we check !alias_set_subset_of (base1_alias_set,
base2_alias_set) instead here?
Any other languages supported by GCC that makes a difference?
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug middle-end/96281] TBAA does not work as expected for a simple test case
2020-07-22 9:07 [Bug other/96281] New: TBAA does not work as expected for a simple test case felix.yang at huawei dot com
@ 2020-07-22 14:24 ` rguenth at gcc dot gnu.org
2021-12-22 10:20 ` [Bug tree-optimization/96281] " pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-22 14:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96281
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|other |middle-end
Status|UNCONFIRMED |NEW
Keywords| |missed-optimization
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2020-07-22
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Memory reference 1: s_13(D)->threadid
Memory reference 2: history_h[_3][i_24][j_25]
Querying dependency of refs 1 and 2: dependent.
Querying RAW dependencies of ref 1 in loop 2: dependent
Querying RAW dependencies of ref 1 in loop 1: dependent
so in the inner loop we see
<bb 9> [local count: 1040670577]:
<bb 3> [local count: 1057206201]:
# j_25 = PHI <0(5), j_16(9)>
_3 = s_13(D)->threadid;
_4 = history_h[_3][i_24][j_25];
_5 = _4 + 1;
_6 = _5 >> 1;
history_h[_3][i_24][j_25] = _6;
j_16 = j_25 + 1;
if (j_16 != 64)
goto <bb 9>; [98.44%]
else
goto <bb 4>; [1.56%]
and while on the entry edge we can CSE s_13(D)->threadid (later PRE does this)
we cannot prove that history_h[_3][i_24][j_25] = _6 does not alters its value.
This looks like a missed optimization as the very same reference is
read before the write. We might also be able to use path-based
disambiguation here. That said, 's_13(D)->threadid' should have the
base_alias_set of struct state but then the comment suggests we
know nothing about the dynamic type.
Needs more thoughts and analysis.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug tree-optimization/96281] TBAA does not work as expected for a simple test case
2020-07-22 9:07 [Bug other/96281] New: TBAA does not work as expected for a simple test case felix.yang at huawei dot com
2020-07-22 14:24 ` [Bug middle-end/96281] " rguenth at gcc dot gnu.org
@ 2021-12-22 10:20 ` pinskia at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-12-22 10:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96281
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |tree-optimization
Severity|normal |enhancement
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-12-22 10:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-22 9:07 [Bug other/96281] New: TBAA does not work as expected for a simple test case felix.yang at huawei dot com
2020-07-22 14:24 ` [Bug middle-end/96281] " rguenth at gcc dot gnu.org
2021-12-22 10:20 ` [Bug tree-optimization/96281] " pinskia 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).