public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Richard Biener <rguenth@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r14-297] wrong GIMPLE from (bit_field_ref CTOR ..) simplification
Date: Thu, 27 Apr 2023 11:21:59 +0000 (GMT)	[thread overview]
Message-ID: <20230427112159.2A8B93858C31@sourceware.org> (raw)

https://gcc.gnu.org/g:a82c6ab0aade4124e1903dda6f6f85c4c317fcec

commit r14-297-ga82c6ab0aade4124e1903dda6f6f85c4c317fcec
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Apr 24 13:20:25 2023 +0200

    wrong GIMPLE from (bit_field_ref CTOR ..) simplification
    
    When we simplify a BIT_FIELD_REF of a CTOR like { _1, _2, _3, _4 }
    and attempt to produce (view converted) { _1, _2 } for a selected
    subset we fail to realize this cannot be done from match.pd since
    we have no way to write the resulting CTOR "operation" and the
    built CTOR { _1, _2 } isn't a GIMPLE value.
    
    This kind of simplifications have to be done in forwprop (or would
    need a match.pd syntax extension) where we can split out the CTOR
    to a separate stmt.
    
    The following disables this particular simplification when we are
    simplifying GIMPLE.  With enhanced IL checking this otherwise
    causes ICEs in the testsuite from vectorized code.
    
            * match.pd (BIT_FIELD_REF CONSTRUCTOR@0 @1 @2): Do not
            create a CTOR operand in the result when simplifying GIMPLE.

Diff:
---
 gcc/match.pd | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/match.pd b/gcc/match.pd
index 34e1a5c1b46..c4320781f5b 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -7456,10 +7456,15 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 			     ? type
 			     : build_vector_type (TREE_TYPE (TREE_TYPE (ctor)),
 						  count * k));
+	      /* We used to build a CTOR in the non-constant case here
+		 but that's not a GIMPLE value.  We'd have to expose this
+		 operation somehow so the code generation can properly
+		 split it out to a separate stmt.  */
 	      res = (constant_p ? build_vector_from_ctor (evtype, vals)
-		     : build_constructor (evtype, vals));
+		     : (GIMPLE ? NULL_TREE : build_constructor (evtype, vals)));
 	    }
-	    (view_convert { res; }))))))
+	    (if (res)
+	     (view_convert { res; })))))))
       /* The bitfield references a single constructor element.  */
       (if (k.is_constant (&const_k)
 	   && idx + n <= (idx / const_k + 1) * const_k)

                 reply	other threads:[~2023-04-27 11:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230427112159.2A8B93858C31@sourceware.org \
    --to=rguenth@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).