public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Martin Liska <marxin@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/marxin/heads/loop-unswitching-switch-v3)] Revert "Revert "Get rid of all float-int special cases in validate_subreg."" Date: Mon, 13 Sep 2021 13:26:43 +0000 (GMT) [thread overview] Message-ID: <20210913132643.99913385781C@sourceware.org> (raw) https://gcc.gnu.org/g:2a171a5cace95acb085953f153da5b1be9a673aa commit 2a171a5cace95acb085953f153da5b1be9a673aa Author: Martin Liska <mliska@suse.cz> Date: Mon Sep 13 14:59:19 2021 +0200 Revert "Revert "Get rid of all float-int special cases in validate_subreg."" This reverts commit 57b7c432cce893e1ba60d9b94a9606df6b419379. Diff: --- gcc/emit-rtl.c | 40 ---------------------------------------- 1 file changed, 40 deletions(-) diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index e6158f243c0..0ba110879aa 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -922,46 +922,6 @@ validate_subreg (machine_mode omode, machine_mode imode, poly_uint64 regsize = REGMODE_NATURAL_SIZE (imode); - /* ??? This should not be here. Temporarily continue to allow word_mode - subregs of anything. The most common offender is (subreg:SI (reg:DF)). - Generally, backends are doing something sketchy but it'll take time to - fix them all. */ - if (omode == word_mode) - ; - /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though store_bit_field - is the culprit here, and not the backends. */ - else if (known_ge (osize, regsize) && known_ge (isize, osize)) - ; - /* Allow component subregs of complex and vector. Though given the below - extraction rules, it's not always clear what that means. */ - else if ((COMPLEX_MODE_P (imode) || VECTOR_MODE_P (imode)) - && GET_MODE_INNER (imode) == omode) - ; - /* ??? x86 sse code makes heavy use of *paradoxical* vector subregs, - i.e. (subreg:V4SF (reg:SF) 0) or (subreg:V4SF (reg:V2SF) 0). This - surely isn't the cleanest way to represent this. It's questionable - if this ought to be represented at all -- why can't this all be hidden - in post-reload splitters that make arbitrarily mode changes to the - registers themselves. */ - else if (VECTOR_MODE_P (omode) - && GET_MODE_INNER (omode) == GET_MODE_INNER (imode)) - ; - /* Subregs involving floating point modes are not allowed to - change size. Therefore (subreg:DI (reg:DF) 0) is fine, but - (subreg:SI (reg:DF) 0) isn't. */ - else if (FLOAT_MODE_P (imode) || FLOAT_MODE_P (omode)) - { - if (! (known_eq (isize, osize) - /* LRA can use subreg to store a floating point value in - an integer mode. Although the floating point and the - integer modes need the same number of hard registers, - the size of floating point mode can be less than the - integer mode. LRA also uses subregs for a register - should be used in different mode in on insn. */ - || lra_in_progress)) - return false; - } - /* Paradoxical subregs must have offset zero. */ if (maybe_gt (osize, isize)) return known_eq (offset, 0U);
reply other threads:[~2021-09-13 13:26 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=20210913132643.99913385781C@sourceware.org \ --to=marxin@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: linkBe 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).