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