[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 #7 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #5)
> (In reply to Jacob Lifshay from comment #2)
> > I think the intrinsics should be designed differently and share their syntax
> > with the clang version:
> 
> what you propose is a massive amount of work, and is based on the
> (equally-as-harmful-as-SIMD) principle of "one vector instruction, one
> intrinsic".

No matter how you express it in C/C++, it has to eventually translate to
something very similar to the intrinsics I proposed. That's just how compilers
work.

> given the huge amounts of time involved it also makes it impractical to
> apply for a grant.

I'd assume gcc allows intrinsics to be dynamically created (or by Python/other
compile-time code generation):
sprintf(name, "__sv_%s%s", sat ? "_saturated" : "", op_name);
gcc_define_intrinsic(name, ...);
which means that all the intrinsics can be generated in a 100-200 line nested
loop.

Assuming GCC is similar to every optimizing compiler I've worked on (mostly
LLVM) I'm pretty sure that the IR would need instructions like those intrinsics
no matter how it's represented in C/C++, so, obviously, it'll be less work to
not have to do an additional translation step in the frontend.

The hard part that would be required for either your or my proposal, luke, is
in the instruction selection stage, and there it is done using pattern
matching. the new patterns are mostly copy/paste and/or can also be done using
a few hundred/thousand line loop to generate them using Python when gcc is
compiled.

> have the *variables* be marked as scalar or vector.  assume that the
> *developer* is intelligent enough to mark them correctly.

The problem is that your approach is highly likely to be waay more work in the
compiler, since the whole frontend has to be modified to add the new variable
kinds, the implicit SV state, etc. The approach I proposed maps almost directly
to the IR.

Also, having the *types* be vector/scalar instead of *variables* enables
building much nicer abstractions over them using C++ and templates. If the
*variables* are marked as vector/scalar, then they can't be easily abstracted
over, preventing many use cases at design-time.

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