This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Intrinsic functions for SPARC VIS instructions.

Eric Botcazou <> writes:

> >  I've been using the UltraSPARC IIi users manual.  The uses Sun expects
> > are addr + offset, so I guess we should use that as well.
> Yes, we should try to follow the VIS prototypes as much as possible.
> You didn't answer:
> > I see you don't generate the move if the target is not NULL but not used
> > as op[0].  I presume it's the correct behaviour for
> Is the question that dumb or...? ;-)

 No, I simply missed it in the reply.  I believe it is.  Both rs6000 and i386
only generate a reg rtx if something doesn't seem correct about target.
> >  Except the assert ensures we don't write over random memory.  That
> > doesn't really matter since we would abort anyway.
> Yes; it's your call anyway.
> >  The first one.  From the testing I've done I've noticed that multiplying
> > by 0 returns zero, but multiplying by non-zero, e.g. 1, generates a
> > fmul8?x16? instruction, which is what we want.
> I'm not thrilled by this but I suppose I can live with it.

 I'd rather have something specified as a multiply instead of nothing.

> >  The thing is faligndata uses part of the gsr to align select which parts
> > of %1 and %2 are put into %0.  So if someone where to do something crazy
> > like align the address of a pointer that is 3 bytes off an 8 byte boundary
> > then load two V4HI vectors and try to align those two vectors, the result
> > would not be what was expected.
> I think I see what you mean; however, I don't think this really matters.  My 
> understanding is that alignaddr/faligndata can be used to load one 8-byte 
> quantity aligned on a byte boundary, whatever the mode it has.  Of course the 
> two 8-byte quantities that are used as an intermediary step barely means 
> something for the mode, but we don't really care.

 I'd like some comment in here, but I think whatever comment is needed is
more appropriate for whatever is added for misaligned loads.
> > > I think the insn is fully symmetric wrt to its 2 operands so you should
> > > write a fully symmetric pattern here.  You also need to use '%r' for
> > > operands that might be zero (see sparc.c:print_operand).

 Thanks for the pointer, this is what I was looking for to do subvectors.

> >  Are you saying both operands should be:
> > (match_operand:P ? "reg_or_0_operand" "%r")
> Sorry, unexpected notation collision.  I think both operands should be
> (match_operand:P ? "reg_or_0_operand" "r")
> because there is no canonicalization here (although passing 0 as the first 
> argument of vis_alignaddr is unlikely).  However you need to use "%r" 
> instead of "%" only, in the output template, for register operands that can be 
> zero, so that (const_int 0) is translated into %g0.

 I'd noticed that other patterns had done this.  Unfortunatly the testing I
had done didn't use %g0 no matter what i seemed to do.

 I think we want the following for alignaddr:

(define_insn "alignaddr<P:mode>_vis"
  [(set (match_operand:P 0 "register_operand" "=r")
        (unspec:P [(match_operand:P 1 "reg_or_0_operand" "%rJ")
                   (match_operand:SI 2 "reg_or_0_operand" "rJ")]
  "alignaddr\t%r1, %r2, %0")

> > > It occured to me that we could use alignaddr/faligndata to implement
> > > byte-aligned load operations in 64-bit mode (see pages 70 and 71 in the
> > > VIS manual).  It turns out that this would exactly match RTH's unaligned
> > > load patch when
> > > the bitfield is byte-aligned (probably modulo signedness).
> >
> >  Probably, we can also use them to fixed the vectorizer fails.  I don't
> > know how to do that yet though.
> Indeed, that could be a good starting point.
> -- 
> Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]