[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e0a5daf81f2c79a0275eccd7c1a25349990a7a4d commit r12-837-ge0a5daf81f2c79a0275eccd7c1a25349990a7a4d Author: Richard Biener Date: Mon May 17 13:56:14 2021 +0200 middle-end/100582 - fix array_at_struct_end_p for vector indexing Vector indexing leaves us with ARRAY_REFs of VIEW_CONVERT_EXPRs, sth which array_at_struct_end_p considers a array-at-struct-end even when there's an underlying decl visible. The following fixes the latter. 2021-05-17 Richard Biener PR middle-end/100582 * tree.c (array_at_struct_end_p): Get to the base of the reference before looking for the underlying decl. * gcc.target/i386/pr100582.c: New testcase.
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #4 from rguenther at suse dot de --- On Mon, 17 May 2021, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 > > --- Comment #3 from Hongtao.liu --- > (In reply to Richard Biener from comment #2) > > First of all we fail to if-convert because we think > > > > iftmp.0_9 = VIEW_CONVERT_EXPR(a)[i_15]; > > tree could trap... > > > > which is because we're concerned about out-of-bound access of 'a' and treat > > this as a array-at-struct-end. > > The tripcount of loop is constant, and the compiler should be able to analyze > that a[i] is not out of bounds, can't scev or vrp helps here? Yes, it works with a fix I am testing right now (still the actual ranges recorded in the IL are [0, 32]). diff --git a/gcc/tree.c b/gcc/tree.c index 01eda553a65..8afba598eb5 100644 --- a/gcc/tree.c +++ b/gcc/tree.c @@ -12550,13 +12550,11 @@ array_at_struct_end_p (tree ref) || ! TYPE_MAX_VALUE (TYPE_DOMAIN (atype))) return true; - if (TREE_CODE (ref) == MEM_REF - && TREE_CODE (TREE_OPERAND (ref, 0)) == ADDR_EXPR) -ref = TREE_OPERAND (TREE_OPERAND (ref, 0), 0); - /* If the reference is based on a declared entity, the size of the array is constrained by its given domain. (Do not trust commons PR/69368). */ - if (DECL_P (ref) + ref = get_base_address (ref); + if (ref + && DECL_P (ref) && !(flag_unconstrained_commons && VAR_P (ref) && DECL_COMMON (ref)) && DECL_SIZE_UNIT (ref)
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #3 from Hongtao.liu --- (In reply to Richard Biener from comment #2) > First of all we fail to if-convert because we think > > iftmp.0_9 = VIEW_CONVERT_EXPR(a)[i_15]; > tree could trap... > > which is because we're concerned about out-of-bound access of 'a' and treat > this as a array-at-struct-end. The tripcount of loop is constant, and the compiler should be able to analyze that a[i] is not out of bounds, can't scev or vrp helps here?
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-05-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Richard Biener --- First of all we fail to if-convert because we think iftmp.0_9 = VIEW_CONVERT_EXPR(a)[i_15]; tree could trap... which is because we're concerned about out-of-bound access of 'a' and treat this as a array-at-struct-end.
[Bug middle-end/100582] vectorize failed to generate VEC_COND_EXPR for v32qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100582 --- Comment #1 from Hongtao.liu --- Also for short, not optimal for int.
