[llvm-dev] vectorisation, risc-v

Wed Aug 8 01:27:40 PDT 2018

On 6 August 2018 at 17:47, Luke Kenneth Casson Leighton via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> [hi, please do cc me to maintain thread integrity, i am subscribed digest]
>
> On Mon, Aug 6, 2018 at 2:32 PM, Alex Bradbury <asb at lowrisc.org> wrote:
>>> 1. I note that the separation between LLVM front and backend looks like
>>> adding SV experimental support would be a simple matter of doing the backend
>>> assembly code translator, with little to no modifications to the front end
>>> needed, would that be about right? Particularly if LLVM-RV already adds a
>>> variable length concept.
>>
>> As with most compilers you can separate the frontend, middle-end and
>> backend. Adding SV experimental support would definitely, as you say,
>> require work in the backend (supporting lowering of IR to machine
>> instructions) but potentially also middle-end modifications (IR->IR
>> transformations) to enable the existing vectorisation passes.
>
>  can you elaborate on that at all, or point me in the direction of
> some docs?  or is it something that's... generally understood?  if i
> can translate what you're saying to concepts that i understand ffrom
> prior experience: the people who helped developed pyjs (a
> python-to-javascript language *translator*), we wrote a python-to-AST
> parser (actually... just took parts of lib2to3, wholesale!), then
> added in "AST morphers" which would walk the AST looking for patterns
> and actually *modify* the AST in-memory to a more javascript-like
> format, and *then* handed it over to the JS outputter.
>
> the biggest of these was, if i recall the one that massively rewrote
> the AST to add proper support for python "yield".
>
> if i understand correctly, the intermediary morphing (IR->IR) is i
> *think* the same thing, does that sound about right?  that you have an
> IR, but that, for the target ISA which has certain concepts that are
> less (or more) efficient, the IR needs rewriting from the
> "general-purpose" original down to a more "architecturally-specific"
> IR.

Thanks for asking the question. A general starting point might be
https://en.wikipedia.org/wiki/Compiler#Three-stage_compiler_structure
and a more LLVM-specific one would be
http://www.aosabook.org/en/llvm.html

You typically want optimisations to be implemented as IR
transformations where possible, allowing them to be reused across
multiple backends (and indeed, different language frontends). Though
these IR passes will often operate with knowledge of the target
architecture.

>>> It is worth emphasising that this shall not be a private proprietary hard
>>> fork of llvm, it is an entirely libre effort including the GPGPU (I read
>>> Alex's lowRISC posts on such private forking practices, a hard fork would be
>>> just insane and hugely counterproductive), so in particular regard to (4)
>>> documentation, guidelines and recommendations likely to result in the
>>> upstreaming process going smoothly also greatly appreciated.
>>
>> One additional thought: I think RISC-V is somewhat unique in LLVM in
>> that implementers are free to design and implement custom extensions
>> without need for prior approval. Many such implementers may wish to
>> see upstream LLVM support for their extensions.
>
>  i don't know if you followed the isa-conflict-resolution discussion
> (which was itself ironically... full of conflict), i am... well,
> there's no easy way to say this, so i'll just say it straight: just as
> with gcc, if upstream LLVM accepts such extension support upstream
> (which implies that, publicly, that opcode is now permanently and
> irrevocably world-wide "taken over" and is *permanently* and
> implicitly *exclusively* reserved by that implementor) without them
> being able to switch it off, i.e. having something that's exactly or
> is orthogonal to the isa-mux proposal (which is exactly like the 386
> "segment offset" concept... except for instructions), LLVM-RISC-V will
> get into an absolute world of pain.

This risks getting well off-topic for llvm-dev. I agree that where ISA
design or management issues impact our ability to deliver a high
quality compiler toolchain it becomes highly relevant, but as I
outline below, I'm not sure the challenges posed for compiler
toolchains are as great as you fear.

> the very first time that LLVM has to generate (support) two uses of
> the exact same binary instruction encoding with two completely
> different meanings, that's it: RISC-V will be treated exactly like
> Altivec / SSE for PowerPC, i.e. dead.
>
> so please, please, guys, for goodness sake, please: when it comes to
> upstreaming non-standard custom extensions that "take over" opcode
> space in ways that *can't be switched off*, please for goodness sake
> put your foot down and say "no, sorry, you'll have to maintain this
> yourself as an unsupported hard fork".
>
> think about it: you let even *one* team make a public declaration "we
> effectively own this custom opcode, now", that's it: nobody else,
> anywhere in the world, can ever publicly consider using it.  and you
> know how few custom opcodes there are [in the 32-bit space].  two.
>
> i can't.... i can't begin to express how absolutely critical this is,
> to the entire RISC-V ecosystem.

Let's separate the issues here.

1) Should the RISC-V Foundation take a more active role in policing
the opcode extension space?

2) Would the existence of multiple custom extensions with overlapping
encodings pose technical challenges for the LLVM project?

For 1), I have lots of opinions, but ultimately that's a RISC-V
discussion rather than an LLVM discussion. For 2) I think not really.
If someone wanted to upstream support for custom extensions I'd
strongly urge them to put in the effort to work with the RISC-V
community to finalise a sensible proposal on ELF attributes which
describes the ISA string a given binary was compiled to target. With
that in place linkers, loaders and other tools can detect potential
issues and at least provide a sensible error for end-users. With the
in place, there's no reason LLVM can't support -march=rv32imacxfoo as
well as -march=rv32imaxbar even if the foo and bar extensions have
overlapping encodings.

Different vendors wanting to make use of different relocation numbers
(i.e. 192-255 in the range reserved for non-standard ABI extensions)
might pose some implementation challenges - there may be an assumption
that a relocation number for a given target has a single universal
definition, but I'd need to check.

You're right that it might be useful to have the ability to configure
parts of the opcode space to trap, ensuring that extensions that
aren't natively supported can be handled via trap+emulate. But again,
that's a RISC-V implementer discussion, and its value will depend on
how many vendors actually pursue such extensions in practice.

The aspect of this which is highly relevant to compiler implementers
is the management of the 'xname' mnemonics. If ACME Inc wants to
submit support for their 'xneuralnets' extension, should they be
allowed to sit on such a general-purpose name or should we encourage
them to rename to 'xacmeneuralnets'? This would need to be co-ordinate
with GCC of course, and is perhaps something the RISC-V Foundation
should have a policy on.

Best,

Alex