This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Intrinsic functions for SPARC VIS instructions.
Eric Botcazou <firstname.lastname@example.org> 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. I presume it's the correct behaviour for
> > TARGET_EXPAND_BUILTIN?
> 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:
[(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 http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00444.html 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