[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 #21 from Alexandre Oliva <oliva at libre-soc.org> ---
> thus one potential approach (not one i am recommending) is to literally chuck out a batch of  add r3 add r4 add r5 add r6 instructions from gcc *as scalars* and have a post-analysis phase spot the patterns and vectorise them

this would actually avoid one problem that we're going to face, namely, that
operations on vectors, as far as GCC is concerned, are parallel, rather than
sequential.

I can't immediately see how to model the fact that a single insn actually takes
multiple steps, and the output of one step may be an input for another.  The
only support GCC has for this is the early-clobber marker, that one is supposed
to use on an output when it must NOT overlap with inputs.  That's the
recommended modelling when the insn may be split after register allocation, and
the solution involves preventing the compiler from reusing input registers as
so-marked outputs.

But when you've got vectors and you wish to exploit the fact that the
iterations are sequential, preventing overlapping allocations won't cut it. 
Though you probably wouldn't be doing such tricks through the compiler to begin
with, so maybe it is fine, after all.


Regardless, I'm coming to think that we may be able to save ourselves a lot of
headaches in the tooling side, out of this significant difference from other
"vector" systems, by having our vectors modelled as parallel rather than
sequential.  In most cases, it won't matter, because there won't be overlaps,
but in those that do, the hardware could easily detect it and switch from
counting upwards to downwards when needed to get the semantics of parallel
access right.

Fail-first mode and twin-predication are ones that immediately raise flags of
potential incompatibilities with this change, but it might still be worth at
least considering it.

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