public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/96244] New: Redudant mask load generated
@ 2020-07-20 3:38 crazylht at gmail dot com
2020-07-20 6:56 ` [Bug tree-optimization/96244] " rguenth at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: crazylht at gmail dot com @ 2020-07-20 3:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96244
Bug ID: 96244
Summary: Redudant mask load generated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
cat test.c
---
typedef int v8si __attribute__ ((__vector_size__ (32)));
v8si
foo (v8si a, v8si b, v8si c, v8si d)
{
v8si e;
for (int i = 0; i != 8; i++)
e[i] = a[i] > b[i] ? c[i] : d[i];
return e;
}
---
gcc -Ofast -mavx2 test.c
cat test.c.238t.optimized
---
foo (v8si a, v8si b, v8si c, v8si d)
{
vector(8) int vect_iftmp.19;
vector(8) int vect_iftmp.18;
vector(8) <signed-boolean:32> mask__31.15;
vector(8) int vect_iftmp.14;
vector(8) <signed-boolean:32> mask__28.11;
<bb 2> [local count: 119292720]:
mask__28.11_40 = b_50(D) < a_53(D);
vect_iftmp.14_43 = .MASK_LOAD (&c, 32B, mask__28.11_40); ---> redundant
mask__31.15_44 = b_50(D) >= a_53(D);
vect_iftmp.18_47 = .MASK_LOAD (&d, 32B, mask__31.15_44); ---> redundant
vect_iftmp.19_49 = .VCOND (b_50(D), a_53(D), vect_iftmp.18_47,
vect_iftmp.14_43, 110);
return vect_iftmp.19_49;
---
could be optimized to
---
vect_iftmp.19_49 = .VCOND (b_50(D), a_53(D), d, c);
---
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/96244] Redudant mask load generated
2020-07-20 3:38 [Bug tree-optimization/96244] New: Redudant mask load generated crazylht at gmail dot com
@ 2020-07-20 6:56 ` rguenth at gcc dot gnu.org
2020-07-20 7:33 ` crazylht at gmail dot com
2021-03-24 8:34 ` crazylht at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-07-20 6:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96244
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-07-20
Status|UNCONFIRMED |NEW
Keywords| |missed-optimization
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So one thing to note here is that a masked load of a by-value parameter decl
doesn't make much sense since a load from it cannot trap (unless there's
out-of-bound accesses - which I'm not sure we may simply disregard here).
if-conversion sees
VIEW_CONVERT_EXPR<int[8]>(d)[i_16]
and indeed considers it
iftmp.0_11 = VIEW_CONVERT_EXPR<int[8]>(c)[i_17];
tree could trap...
<bb 3> [local count: 954449105]:
# RANGE [0, 8] NONZERO 15
# i_17 = PHI <0(2), i_13(8)>
# ivtmp_6 = PHI <8(2), ivtmp_4(8)>
_1 = VIEW_CONVERT_EXPR<int[8]>(a)[i_17];
_2 = VIEW_CONVERT_EXPR<int[8]>(b)[i_17];
so range-info is one index too pessimistic here. So IMHO it's not about
"redundant" masked loads, it's about the fact that we end up with loads
at all here. If c and d would not be register arguments we would have to
perform loads and if they might trap we could not elide the masked load.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/96244] Redudant mask load generated
2020-07-20 3:38 [Bug tree-optimization/96244] New: Redudant mask load generated crazylht at gmail dot com
2020-07-20 6:56 ` [Bug tree-optimization/96244] " rguenth at gcc dot gnu.org
@ 2020-07-20 7:33 ` crazylht at gmail dot com
2021-03-24 8:34 ` crazylht at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: crazylht at gmail dot com @ 2020-07-20 7:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96244
--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> so range-info is one index too pessimistic here. So IMHO it's not about
> "redundant" masked loads, it's about the fact that we end up with loads
> at all here. If c and d would not be register arguments we would have to
> perform loads and if they might trap we could not elide the masked load.
compared to masked load, load seems to be be more probably eliminated by
backend for this situation.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/96244] Redudant mask load generated
2020-07-20 3:38 [Bug tree-optimization/96244] New: Redudant mask load generated crazylht at gmail dot com
2020-07-20 6:56 ` [Bug tree-optimization/96244] " rguenth at gcc dot gnu.org
2020-07-20 7:33 ` crazylht at gmail dot com
@ 2021-03-24 8:34 ` crazylht at gmail dot com
2 siblings, 0 replies; 4+ messages in thread
From: crazylht at gmail dot com @ 2021-03-24 8:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96244
Hongtao.liu <crazylht at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-03-24 8:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-20 3:38 [Bug tree-optimization/96244] New: Redudant mask load generated crazylht at gmail dot com
2020-07-20 6:56 ` [Bug tree-optimization/96244] " rguenth at gcc dot gnu.org
2020-07-20 7:33 ` crazylht at gmail dot com
2021-03-24 8:34 ` crazylht at gmail dot com
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).