This is the mail archive of the
mailing list for the GCC project.
Re: Alpha CPU-specific builtins
Richard Henderson <firstname.lastname@example.org> writes:
Thanks a lot for your comments. As I said, I'm new to gcc, so it will
take me a while to understand most of what you said :) I'll try to
implement it, though.
> > + def_builtin ("__builtin_alpha_rpcc", di_ftype, ALPHA_BUILTIN_RPCC);
> Ideally this should take an input. While gas doesn't support the
> syntax at the moment, the "unused" register (I forget whether its's
> RA or RB) is considered an input on EV6, which means that you have a
> mechanism to avoid having the RPCC instruction scheduled too early
> by the reorder buffer.
Interesting, I cannot find this in the architecture handbook nor the
EV6 hardware reference, where is this documented?
> > +(define_insn "minub8"
> > + [(set (match_operand:DI 0 "register_operand" "=r")
> > + (unspec:DI [(match_operand:DI 1 "reg_or_0_operand" "%rJ")
> > + (match_operand:DI 2 "reg_or_8bit_operand" "rI")]
> > + UNSPEC_MINUB8))]
> > + ""
> > + "minub8 %r1,%2,%0"
> > + [(set_attr "type" "mvi")])
> All of these can and should be described with vector modes.
I considered that, but it seems when using vector mode, the variables
have to be declared to be of a special type in C, and cast to and from
normal longs. While this makes sense on architectures which have
special registers and where these casts actually do something, it
seemed a bit annoying for Alpha. What would be the advantages? gcc
could then probably optimize minub8(x, x) or something, but people who
use funny builtins likely wouldn't write code with opportunities for
optimizations like that... The same thing applies to zap, IMHO: I
would normally never write zap(foo, 0xaa), in the example I only did
so because I noticed that gcc would generate better code (at least
with 3.0, 2.95 got it right).
But I'm no expert, perhaps I'm missing something :)