Re: Machine description question

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Sat, Feb 07, 2009 at 03:54:51PM -0500, Jean Christophe Beyler wrote:
> Dear all,
> 
> I have a question about the way the machine description works and how
> it affects the different passes of the compiler. I was reading the GNU
> Compiler Collection Internals and I found this part (in section
> 14.8.1):
> 
>      (define_insn ""
>        [(set (match_operand:SI 0 "general_operand" "=r")
>              (plus:SI (match_dup 0)
>                       (match_operand:SI 1 "general_operand" "r")))]
>        ""
>        "...")
> 
> which has two operands, one of which must appear in two places, and
> 
>      (define_insn ""
>        [(set (match_operand:SI 0 "general_operand" "=r")
>              (plus:SI (match_operand:SI 1 "general_operand" "0")
>                       (match_operand:SI 2 "general_operand" "r")))]
>        ""
>        "...")
> 
> which has three operands, two of which are required by a constraint to
> be identical. 
> 
> 
> My question is :
> - How do the constraints work for match_dup or for when you put "0" as
> a constraint? Since we want the same register but as input and not
> output, how does the compiler set up its dependencies? Does it just
> forget the "=" or "+" for the match_dup or "0" ?

Note, the two are not the same thing before register allocation.  Before
register allocation, in the first example, the argument to the plus must point
to the exact RTL that the result is.  Given that normally a different pseudo
register is used for the output, the first example won't match a lot of insns
that are created.

The two general_operands are distinct and the normal live/death information
will track the insns.  So you are saying that the first general operand is a
write only value, and the second is a read only value.  During register
allocation, the register allocator notices the "0" and then reuses the
register.  In that example, the value of operand1 dies in that insn, replaced
by the value in operand0.

For example, consider a 2 address machine like the 386 (and ignoring things
like LEA).  If the value of operand1 is live after the insn, and operand0 wants
to be %eax, operand1 is in %ebx, and operand2 is in %edx, then the register
allocation typically generates code like:

	movl %ebx, %eax
	addl %edx, %eax

If operand1's value was not needed after the insn, then the compiler would
possibly allocate the output to %ebx, and do:

	addl %edx, %ebx

> 
> - I also read that it is possible to assign a letter with a number for
> the constraint. Does this mean I can do "r0" to say, it's going to be
> an input register but it must look like the one you'll find in
> position 0?

I'm not sure what you are asking here.  If you are talking about the
multi-letter constraints in define_register_constraint, that is basically a way
to extend the machine description for more constraints when you run out of
single letters.

> - My third question is: why not put "+r" as the constraint instead of
> "=r" since we are going to be reading and writing into r0.

Because the output value is not an input to the add in the second example.  It
is an input to the add in the first, due to the use of match_dup.

> - Finally, I have a similar instruction definition, if I use the first
> solution (match_dup), the instruction that will calculate the
> input/output operand 0 sometimes gets removed by the web pass. But if
> I use the second solution (put a "0" constraint), then it is no longer
> removed. Any idea why these two definitions would be treated
> differently in the web pass?

I don't know much about the web pass, however as I said, the two definitions
are fundamentally different.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com