public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/vendors/riscv/heads/gcc-13-with-riscv-opts)] mode-switching: Tweak entry/exit handling
@ 2023-11-21  4:11 Jeff Law
  0 siblings, 0 replies; only message in thread
From: Jeff Law @ 2023-11-21  4:11 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:4eef04841c330d681d4e1b404f03da84fca7334a

commit 4eef04841c330d681d4e1b404f03da84fca7334a
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Sat Nov 11 17:28:57 2023 +0000

    mode-switching: Tweak entry/exit handling
    
    An entity isn't transparent in a block that requires a specific mode.
    optimize_mode_switching took that into account for normal insns,
    but didn't for the exit block.  Later patches misbehaved because
    of this.
    
    In contrast, an entity was correctly marked as non-transparent
    in the entry block, but the reasoning seemed a bit convoluted.
    It also referred to a function that no longer exists.
    Since KILL = ~TRANSP, the entity is by definition not transparent
    in a block that defines the entity, so I think we can make it so
    without comment.
    
    Finally, the exit handling was nested in the entry handling,
    but that doesn't seem necessary.  A target could say that an
    entity is undefined on entry but must be defined on return,
    on a "be liberal in what you accept, be conservative in what
    you do" principle.
    
    gcc/
            * mode-switching.cc (optimize_mode_switching): Mark the exit
            block as nontransparent if it requires a specific mode.
            Handle the entry and exit mode as sibling rather than nested
            concepts.  Remove outdated comment.
    
    (cherry picked from commit e59ec35276599805cdc6c3979d8a167b027d286e)

Diff:
---
 gcc/mode-switching.cc | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/gcc/mode-switching.cc b/gcc/mode-switching.cc
index 03dd4c1ebe4..1145350ca26 100644
--- a/gcc/mode-switching.cc
+++ b/gcc/mode-switching.cc
@@ -650,34 +650,30 @@ optimize_mode_switching (void)
 	}
       if (targetm.mode_switching.entry && targetm.mode_switching.exit)
 	{
-	  int mode = targetm.mode_switching.entry (e);
-
 	  info[post_entry->index].mode_out =
 	    info[post_entry->index].mode_in = no_mode;
-	  if (pre_exit)
-	    {
-	      info[pre_exit->index].mode_out =
-		info[pre_exit->index].mode_in = no_mode;
-	    }
 
+	  int mode = targetm.mode_switching.entry (e);
 	  if (mode != no_mode)
 	    {
-	      bb = post_entry;
-
-	      /* By always making this nontransparent, we save
-		 an extra check in make_preds_opaque.  We also
-		 need this to avoid confusing pre_edge_lcm when
-		 antic is cleared but transp and comp are set.  */
-	      bitmap_clear_bit (transp_all, bb->index);
-
 	      /* Insert a fake computing definition of MODE into entry
 		 blocks which compute no mode. This represents the mode on
 		 entry.  */
-	      info[bb->index].computing = mode;
+	      info[post_entry->index].computing = mode;
+	      bitmap_clear_bit (transp_all, post_entry->index);
+	    }
 
-	      if (pre_exit)
-		info[pre_exit->index].seginfo->mode =
-		  targetm.mode_switching.exit (e);
+	  if (pre_exit)
+	    {
+	      info[pre_exit->index].mode_out =
+		info[pre_exit->index].mode_in = no_mode;
+
+	      int mode = targetm.mode_switching.exit (e);
+	      if (mode != no_mode)
+		{
+		  info[pre_exit->index].seginfo->mode = mode;
+		  bitmap_clear_bit (transp_all, pre_exit->index);
+		}
 	    }
 	}

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-11-21  4:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-21  4:11 [gcc(refs/vendors/riscv/heads/gcc-13-with-riscv-opts)] mode-switching: Tweak entry/exit handling Jeff Law

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).