Problem with `unspec' construct

[Nitin Jain]

Dear Sir,

Thanks for your reply. It clarify some of my doubt but still i have some 
doubt.

 o  What i understand is that UNSPEC is used for such operation for which 
    there is no direct construct (operation) available in GCC. The reason 
    behind this thinking is the following comments from i386.md (gcc-3.2)
    ;; UNSPEC usage:
    ;; 8  This is a reference to a symbol's @PLT address.
    ;; 9  This is an `fnstsw' operation.
    ;; 10 This is a `sahf' operation.
    ;; 11 This is a `fstcw' operation

    
 o  Following is an example of UNSPEC uses. From i386.md  
     (define_insn "*cmpfp_2_sf_1"
      [(set (match_operand:HI 0 "register_operand" "=a")
       (unspec:HI
          [(compare:CCFP
            (match_operand:SF 1 "register_operand" "f")
            (match_operand:SF 2 "nonimmediate_operand" "fm"))] 9))]

    Here operation corresponding to unspec (9) is `fnstsw' which store the 
    FPU status register into a 16 bit memory location or the ax register.

    But `cmpfp_2_sf_1' is not an standard operation name with respect to 
    GCC so there should be some `define_expand' for this `define_expr'. I 
    am not sure whether i am right or wrong but is the following `define_expand'
    correspond to the previous `define_expr'. If not then what is the 
    corresponding `define_expand' for it.

     (define_expand "cmpsf"
      [(set (reg:CC 17)
       (compare:CC (match_operand:SF 0 "cmp_fp_expander_operand" "")
                    (match_operand:SF 1 "cmp_fp_expander_operand" "")))]

    Reason behind the confusion is that the syntax of `define_expr' and 
    `define_expand' is different. Please clarify this.

 o  This doubt is not directly related to the UNSPEC stuff. In a reply to 
    one of my doubt, somebody wrote that some `define_insn' in .md file 
    have standard name like `addsi3' but rest have non-standard name. 
    There is again a distinction between the second class of `define_insn'. 
    Names which start with `*' and without `*'. Difference between two is 
    that the name of `define_insn' whose name start with  `*' is dumped in 
    the intermediate code.  Is it right or not? Doubt is because of the 
    following portion of intermediate code: 
     
     (insn 61 60 62 (set (reg:CC 17 flags)
      (unspec:CC[
         (reg:HI 0 ax [69]) ]  10)) 31 {x86_sahf_1} (nil) (nil))

    And i think that `x86_sahf_1' is not an standard name for GCC.

Waiting for your reply.

Thanks and regard.

Nitin
---------------------------
Nitin Jain (H-12/#A-415)
Computer Science and Engg,
IIT BOMBAY,
POWAI, MUMBAI 400076
Phone : 4748 (Lab)
---------------------------


On Sun, 25 Apr 2004, Zack Weinberg wrote:

> 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
>