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: unshare_all_rtl missed some rtl



  In message <200001111739.JAA03678@localhost.cygnus.com>you write:
d  > >   > (define_insn "divmodsi4"
  > >   >   [(set (match_operand:SI 0 "general_operand" "=d")
  > >   > 	(div:SI (match_operand:SI 1 "general_operand" "0")
  > >   > 		(match_operand:SI 2 "general_src_operand" "dmSTK")))
  > >   >    (set (match_operand:SI 3 "general_operand" "=d")
  > >   > 	(mod:SI (match_dup 1) (match_dup 2)))]
  > >   >   "TARGET_68020 && !TARGET_5200"
  > >   >   "*
  > >   > {
  > >   >   if (find_reg_note (insn, REG_UNUSED, operands[3]))
  > >   >     return \"divs%.l %2,%0\";
  > >   >   else
  > >   >     return \"divsl%.l %2,%3:%0\";
  > >   > }")
  > >   > 
  > >   > and various test-cases were failing because:
  > >   > 
  > >   > - the constraint allows a memory operand, like an incoming argument; 
  > > I don't see why that in and of itself is wrong.  The first argument to a
  > > div instruction (operand #2 in the RTL) can be a memory operand on the m6
  > 8k.
  > 
  > Operands 0 and 1 are register_operand because "d" only matches a
  > register.
Silly me.  I was looking at the constraints, not the predicates.  Silly, silly
me, I should know better.

  > >   > - the rtx for incoming arguments are shared between the DECL_RTL of
  > >   >   the function's arguments as trees and the actual rtl of the
  > >   >   function;
  > > Isn't this a requirement for virtual register instantiation and function
  > > inlining?  Presumably I'm missing something here since it sounds like Jim
  > > suggested that changing this would fix the problem (see below).
  > 
  > Not that I know of.  At least, function inlining seems to work 
  > with my patch, and virtual register instantiation is what my patch fixes.
But in both inlining and instantiation we depend on certain hunks of RTL
to be shared.  Your patch reduces the sharing and thus I'm concerned that
we'll break (possibly in obscure ways) instantiation and inlining.

An example of how we depend on sharing in instantiation is the handling of
MEM/ADDRESSOF expressions.

We build up a hash table which contains the insns which reference a particular
MEM.  The key for the hash table is the address of the MEM in question.

If we're not sharing MEMs properly this code might not work (in fact, I ran
into this myself when trying to fix incorrectly shared MEM expressions in
the PA64 port).

jeff


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