This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: fix for explicit SET modes



  In message <199808141552.IAA20219@dm.cobaltmicro.com>you write:
  >    Date: Fri, 14 Aug 1998 09:47:27 -0600
  >    From: Jeffrey A Law <law@hurl.cygnus.com>
  > 
  >    I think we emit markers now to delimit the start/end of jump
  >    tables, so we could search for those markers now instead of relying
  >    on the DImode hack.
  > 
  > Then please do it this way if you can.
  > 
  > A secondary thing I am concerned about here, is that if we just fix
  > this one weird case which happens to not be relevant, everyone will
  > end up being consistent (ie. not generate SET's with explicit modes).
  > 
  > Thus we can perform the consistency checking if we wanted to in
  > gen_rtx_SET calls, I think this is a good thing :-)
It turns out that it's still desirable to mark the jumps within the
switch tables

While we can use the jump table markers to efficiently determine if we
are in a switch table at assembly output time, they are mighty inefficient 
for branch shortening and other code which wants to look up the length
of an insn  -- you have to go searching through the rtl chain to see
if you happen to be inside a set of markers.  Painful for iterate until
nothing changes code like in shorten_branches.

In the interest of getting this little sanity check, I'll mark these
jumps in another manner (mode on the jump insn itself, which shouldn't
conflict with anything right now since haifa doesn't schedule jumps).

Odds are I'll have to change the marking scheme again one day, but
such is life.

So remove the PA from the list of ports which do bad things with the
mode of SETs.  I'll be checking in the necessary PA backend changes
shortly.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]