i386.md TARGET_MOVE confusion / questions

Jeffrey A Law law@cygnus.com
Tue Jan 13 23:31:00 GMT 1998


  In message < 199801140431.XAA14445@jwlab.FEITH.COM >you write:
  > I have some questions about the use of TARGET_MOVE in i386.md.
  > 
  >   1) Why do the following two patterns exist?  It would seem to me
  >      that one pattern that just checks for !TARGET_PUSH_MEMORY
  >      would enough.  BTW, these two patterns also exist for HI.
  > 
  >        (define_insn ""
  >          [(set (match_operand:SI 0 "push_operand" "=<")
  >                (match_operand:SI 1 "nonmemory_operand" "ri"))]
  >          "!TARGET_PUSH_MEMORY && TARGET_MOVE"
  >          "push%L0 %1")
  > 
  >        (define_insn ""
  >          [(set (match_operand:SI 0 "push_operand" "=<")
  >                (match_operand:SI 1 "nonmemory_operand" "ri"))]
  >          "!TARGET_PUSH_MEMORY && !TARGET_MOVE"
  >          "push%L0 %1")
I tend to agree -- can you send a patch that cleans this up?

  > 
  >   2) It appears from the following pattern that the intent of
  >      TARGET_MOVE is to cause RTL for memory to memory moves to
  >      appear as memory to register to memory moves.
Agreed.  ANd that seems to agree with the comments around the definition
of TARGET_MOVE.

[ ... ]

  >      However the code for movsf seems to indicate that TARGET_MOVE means
  >      leave RTL for memory to memory transfer alone without changing the
  >      RTL to appear as memory to register to memory.
Weird.  There's certainly some inconsistencies here :(


  >   3) This also brings up the question of why are push_operands handled
  >      differently for SI and SF.  In the case of SI patterns checking
  >      for push_operand are defined before movsi.  In the case of SF
  >      movsf checks for push_operand.  Any reason that SF can't be
  >      handled in the same fashion as SI for push_operand (i.e. put
  >      patterns for handling SF pushes before movsf and don't bother
  >      having movsf worry about pushes)?
I don't know enough about the x86 to say either way... Stan or Marc care
to comment?

jeff



More information about the Gcc-bugs mailing list