public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tamar Christina <tamar.christina@arm.com>
To: gcc-patches@gcc.gnu.org
Cc: nd@arm.com, hubicka@ucw.cz, ubizjak@gmail.com,
	kirill.yukhin@gmail.com, hongtao.liu@intel.com
Subject: [PATCH][i386]: Update ix86_can_change_mode_class target hook to accept QImode conversions
Date: Fri, 11 Nov 2022 14:44:55 +0000	[thread overview]
Message-ID: <patch-16561-tamar@arm.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2730 bytes --]

Hi All,

The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is currently
not useful before re-alloc.

In particular before regalloc optimization passes query the hook using ALL_REGS,
but because of the

  if (MAYBE_FLOAT_CLASS_P (regclass))
      return false;

The hook returns false for all modes, even integer ones because ALL_REGS
overlaps with floating point regs.

The vector permute fallback cases used to unconditionally convert vector integer
permutes to vector QImode ones as a fallback plan.  This is incorrect and can
result in incorrect code if the target doesn't support this conversion.

To fix this some more checks were added, however that ended up introducing ICEs
in the i386 backend because e.g. the hook would reject conversions between modes
like V2TImode and V32QImode.

My understanding is that for x87 we don't want to allow floating point
conversions, but integers are fine.  So I have modified the check such that it
also checks the modes, not just the register class groups.

The second part of the code is needed because now that integer modes aren't
uniformly rejected the i386 backend trigger further optimizations.  However the
backend lacks instructions to deal with canonical RTL representations of
certain instructions.  for instance the back-end seems to prefer vec_select 0
instead of subregs.

So to prevent the canonicalization I reject integer modes when the sizes of to
and from don't match and when we would have exited with false previously.

This fixes all the ICEs and codegen regressions, but perhaps an x86 maintainer
should take a deeper look at this hook implementation.

Bootstrapped Regtested on x86_64-pc-linux-gnu and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

	* config/i386/i386.cc (ix86_can_change_mode_class): Update the target
	hook.

--- inline copy of patch -- 
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index c4d0e36e9c0a2256f5dde1f4dc021c0328aa0cba..477dd007ea80272680751b61e35cc3eec79b66c3 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -19682,7 +19682,15 @@ ix86_can_change_mode_class (machine_mode from, machine_mode to,
 
   /* x87 registers can't do subreg at all, as all values are reformatted
      to extended precision.  */
-  if (MAYBE_FLOAT_CLASS_P (regclass))
+  if (MAYBE_FLOAT_CLASS_P (regclass)
+      && VALID_FP_MODE_P (from)
+      && VALID_FP_MODE_P (to))
+    return false;
+
+  /* Reject integer modes if the sizes aren't the same.  It would have
+     normally exited above.  */
+  if (MAYBE_FLOAT_CLASS_P (regclass)
+      && GET_MODE_SIZE (from) != GET_MODE_SIZE (to))
     return false;
 
   if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass))




-- 

[-- Attachment #2: rb16561.patch --]
[-- Type: text/plain, Size: 870 bytes --]

diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index c4d0e36e9c0a2256f5dde1f4dc021c0328aa0cba..477dd007ea80272680751b61e35cc3eec79b66c3 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -19682,7 +19682,15 @@ ix86_can_change_mode_class (machine_mode from, machine_mode to,
 
   /* x87 registers can't do subreg at all, as all values are reformatted
      to extended precision.  */
-  if (MAYBE_FLOAT_CLASS_P (regclass))
+  if (MAYBE_FLOAT_CLASS_P (regclass)
+      && VALID_FP_MODE_P (from)
+      && VALID_FP_MODE_P (to))
+    return false;
+
+  /* Reject integer modes if the sizes aren't the same.  It would have
+     normally exited above.  */
+  if (MAYBE_FLOAT_CLASS_P (regclass)
+      && GET_MODE_SIZE (from) != GET_MODE_SIZE (to))
     return false;
 
   if (MAYBE_SSE_CLASS_P (regclass) || MAYBE_MMX_CLASS_P (regclass))




             reply	other threads:[~2022-11-11 14:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 14:44 Tamar Christina [this message]
2022-11-14  2:14 ` Hongtao Liu
2022-11-14  9:14   ` Tamar Christina
2022-11-16  6:40   ` Hongtao Liu
2022-11-15 11:17 ` Hongtao Liu

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=patch-16561-tamar@arm.com \
    --to=tamar.christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongtao.liu@intel.com \
    --cc=hubicka@ucw.cz \
    --cc=kirill.yukhin@gmail.com \
    --cc=nd@arm.com \
    --cc=ubizjak@gmail.com \
    /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).