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.
