> Thanks for your reply. But I am afraid your pointer does not make it
> clearer to me. The excerpt of "define_insn "<u>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.
> >> 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 ?
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.
> >> 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. :
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 <u>mulsidi3_64bit_split expansion then the instruction you
referred to gets generated. <u>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
> On Wed, Sep 3, 2014 at 3:03 AM, Andrew Haley <aph@xxxxxxxxxx> wrote:
> > On 03/09/14 02:31, Cherry Vanc wrote:
> >> 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 "<u>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<u>\t%1,%2"
> >> [(set_attr "type" "imul")
> >> (set_attr "mode" "SI")])
> >
> > Look at
> >
> > (define_expand "<u>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_<u>mulsidi3_64bit_hilo (hilo, operands[1], operands[2]));
> >
> > ...
> >
> > Andrew.
> >
