[Libre-soc-bugs] [Bug 558] gcc SV intrinsics concept

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=558

--- Comment #63 from Alexandre Oliva <oliva at libre-soc.org> ---
What Jacob said.  I may have misremembered the double+double long double thing
as float+float double.  But pairs of (neighboring) 32-bit GPRs for 64-bit
values in 32-bit mode are definitely a thing, at least ABI-wise.

Anyway, the main point I wanted to warn against was the introduction of new
registers between preexisting registers that are used in ways that require them
to remain contiguous.  That would be a very serious difficulty.  It doesn't
look like CR#.## numbering does that, because I don't see that CRs are used
contiguously anywhere.  Debug info numbering might need remapping, but that's
not a big deal.

A big deal would be having (possibly legacy) opcodes/ABIs that require
registers, from any register file, to be grouped and used together in a way
that required them to be contiguous in a certain way, while having other (new)
opcodes that require them to be grouped in ways that impose different
contiguity requirements, because it would be impossible to satisfy both at the
same time.  That what I was trying to avoid, and that's why I mentioned the
main GCC knobs to configure the parameters for register allocation.

As for vector CC modes, as long as you use the CC modes as outputs to vector
compares, and then use them for predication of vectors of the same length, this
will be (I believe) no different from existing uses of CRs as outputs to scalar
compare insns and inputs to conditional moves (and conditional branches, but
those won't take vectors, I hope ;-)

GCC's "movecc_<mode>" template insn in rs6000.md covers even moving the various
CCmodes from and to memory, through GPRs, but it's still the case that GCC has
no clue about the bit patterns that represent the different values represented
in these modes.  That's left entirely up to the architecture to choose, and
implement consistently between CR-setting and CR-using insns.

In order to use vector CRs as predicates with predefined values, rather than as
ones computed by vector compares, or by vector insns that set vector CRs as
side effects, the programmers who wish to use such predicates will either have
to figure out how to get the right bit patterns loaded into the CR vectors, or
set up other vectors and perform operations between them that set the vectors
accordingly.

Since CRs are smaller than words, it is possible that the same anomaly that I
reported elsewhere about endianness in using bitfields as predicate registers
will apply to CR vectors, and users will have to use integral values that vary
depending on endianness to obtain equivalent CR vector predication.

-- 
You are receiving this mail because:
You are on the CC list for the bug.