Problem with `unspec' construct

[Zack Weinberg]

Nitin Jain <nitinj@cse.iitb.ac.in> writes:

> For example (From i386.md)
> -------------------------------------------------------------------------
> (define_insn "ffssi_1"
>   [(set (match_operand:SI 0 "register_operand" "=r")
>         (unspec:SI [(match_operand:SI 1 "nonimmediate_operand" "rm")] 5))]
>   ""
>   "* return AS2 (bsf%L0,%1,%0);")

Note that you are looking at a very old copy of i386.md.  The ffssi_1
insn is quite different in the current development sources.

> So my doubt is 
>
> o  To which operation, this `unspec' operation or construct will match at 
>    compile time. 

UNSPEC isn't special.  Insns containing UNSPEC are generated under
exactly the same conditions that other insns are generated -
initially, when a named expander or insn is invoked from machine-
independent code (see the "Standard Names" section of the GCC manual);
they can also come from splitters invoked during optimization; in
theory, instruction combination or other optimizations could produce
new patterns containing UNSPEC, but this is unlikely because machine-
independent code doesn't know what an UNSPEC means.

Also, machine-dependent code (CPU.[ch] alongside CPU.md) can create
insns containing UNSPEC, and frequently does.

> o  What is the significance of `5' in `unspec' construct. Manual says that 
>    this is index to some m/c specific operation. So is there some ordering 
>    between those operation.

It is an arbitrary number whose purpose is to distinguish this
particular UNSPEC from others.  In more recent versions of GCC we have
the ability to use symbolic constants for this number, which makes
things much nicer.  There is no meaning to the value 5 being used for
this one.

> o  And finally, are those operation are different from what defined in the 
>    .md file. If yes then where those operation are defined and if not, 
>    then what is the ordering between the operation defined in .md file.

They are different only insofar as the machine-independent optimizers
don't know what they mean, so are very limited in their ability to
optimize through an UNSPEC construct.  Insns that use UNSPEC are
defined in the .md file just the same way that insns that use named
RTL operations are.

I don't understand the question about ordering.  All the patterns in
an .md file are independent.

zw