unspec in machine description file

Discussion:

Cherry Vanc

2014-09-03 01:31:44 UTC

I cannot seem to pin down the scope of the keyword "unspec" in the
machine description files. From the MIPS backend files, I see the word
"unspec" being used in two ways :

1. names of constants (UNSPEC_LOAD_LOW, UNSPEC_LOAD_HIGH, .. so on) :
I understand that these are just names, but Why UNSPEC_ preceding each
name ?
2. some define_insn patterns have the "unspec" rtl expression. What
does "unspec" precisely mean here - unspecified operation ? How does
that work in the RTL generation pass ? E.g. :

(define_insn "mulsidi3_64bit_hilo"
[(set (match_operand:TI 0 "register_operand" "=x")
(unspec:TI
[(mult:DI
(any_extend:DI (match_operand:SI 1 "register_operand" "d"))
(any_extend:DI (match_operand:SI 2 "register_operand" "d")))]
UNSPEC_SET_HILO))]
"TARGET_64BIT && !TARGET_FIX_R4000"
"mult\t%1,%2"
[(set_attr "type" "imul")
(set_attr "mode" "SI")])

Thanks in advance!

Andrew Haley

2014-09-03 10:03:07 UTC

Permalink

Post by Cherry Vanc
I cannot seem to pin down the scope of the keyword "unspec" in the
machine description files. From the MIPS backend files, I see the word
I understand that these are just names, but Why UNSPEC_ preceding each
name ?
2. some define_insn patterns have the "unspec" rtl expression. What
does "unspec" precisely mean here - unspecified operation ? How does
(define_insn "mulsidi3_64bit_hilo"
[(set (match_operand:TI 0 "register_operand" "=x")
(unspec:TI
[(mult:DI
(any_extend:DI (match_operand:SI 1 "register_operand" "d"))
(any_extend:DI (match_operand:SI 2 "register_operand" "d")))]
UNSPEC_SET_HILO))]
"TARGET_64BIT && !TARGET_FIX_R4000"
"mult\t%1,%2"
[(set_attr "type" "imul")
(set_attr "mode" "SI")])

Look at

(define_expand "mulsidi3_64bit_split"
[(set (match_operand:DI 0 "register_operand")
(mult:DI (any_extend:DI (match_operand:SI 1 "register_operand"))
(any_extend:DI (match_operand:SI 2 "register_operand"))))
(clobber (match_operand:DI 3 "register_operand"))]
""
{
rtx hilo;

hilo = gen_rtx_REG (TImode, MD_REG_FIRST);
emit_insn (gen_mulsidi3_64bit_hilo (hilo, operands[1], operands[2]));

...

Andrew.

Cherry Vanc

2014-09-03 17:44:06 UTC

Permalink

Thanks for your reply. But I am afraid your pointer does not make it
clearer to me. The excerpt of "define_insn "mulsidi3_64bit_hilo" "
I specified is from an older version of GCC which I need to stick to,
so I need to understand why and when to use "unspec" as I am extending
a GCC backend based on the MIPS one.

Post by Andrew Haley

Look at
(define_expand "mulsidi3_64bit_split"
[(set (match_operand:DI 0 "register_operand")
(mult:DI (any_extend:DI (match_operand:SI 1 "register_operand"))
(any_extend:DI (match_operand:SI 2 "register_operand"))))
(clobber (match_operand:DI 3 "register_operand"))]
""
{
rtx hilo;
hilo = gen_rtx_REG (TImode, MD_REG_FIRST);
emit_insn (gen_mulsidi3_64bit_hilo (hilo, operands[1], operands[2]));
...
Andrew.

Matthew Fortune

2014-10-06 09:45:34 UTC

Permalink

Post by Cherry Vanc
Thanks for your reply. But I am afraid your pointer does not make it
clearer to me. The excerpt of "define_insn "mulsidi3_64bit_hilo" "
I specified is from an older version of GCC which I need to stick to,
so I need to understand why and when to use "unspec" as I am extending
a GCC backend based on the MIPS one.

Post by Andrew Haley

Post by Cherry Vanc
I understand that these are just names, but Why UNSPEC_ preceding each
name ?

These are just unique values for the various operations which GCC does not
inherently understand. The names give meaning to an unspec operation
but that information will/can only be used by the backend.

Post by Cherry Vanc

Post by Andrew Haley

Post by Cherry Vanc
2. some define_insn patterns have the "unspec" rtl expression. What
does "unspec" precisely mean here - unspecified operation ? How does

Unspec is unspecified in terms of the standard GCC internals. All the core
code knows about the operation is that it has inputs and output(s).

A backend must explicitly expand to a pattern which includes an unspec
in order to generate it. So a named instruction would need to be expanded
and generate an instruction which includes an unspec for it to 'exist'.
(Or an instruction can be just constructed using gen_rtx_UNSPEC.

Andrew's example shows one level up from the pattern you referred to.
As part of mulsidi3_64bit_split expansion then the instruction you
referred to gets generated. mulsidi3_64bit_split itself is not a standard
named instruction so you then need to look at what generates that
instruction explicitly until you hit a standard named instruction.

The multiplication pattern expansion for MIPS is very complex and has
several layers. Perhaps look at another use of UNSPEC/unspec to help you
understand its role.

If you are adding new multiply instructions as part of your work then
you will have to take time to understand the whole set of multiply
instructions before extending them. If the work you are doing will not
get contributed back (which would be a shame) then you could try
simplifying the code to remove the cases which you do not care about
for your project. If you intend to contribute the code back then you
will need to do it properly.

Thanks,
Matthew

Post by Cherry Vanc

Post by Andrew Haley

Look at
(define_expand "mulsidi3_64bit_split"
[(set (match_operand:DI 0 "register_operand")
(mult:DI (any_extend:DI (match_operand:SI 1 "register_operand"))
(any_extend:DI (match_operand:SI 2 "register_operand"))))
(clobber (match_operand:DI 3 "register_operand"))]
""
{
rtx hilo;
hilo = gen_rtx_REG (TImode, MD_REG_FIRST);
emit_insn (gen_mulsidi3_64bit_hilo (hilo, operands[1], operands[2]));
..