Hi,
I’m still seeing the same ie trying to produce SVE instructions but
resulted in NEONs with Clang as of Sep. 10th.
http://lists.llvm.org/pipermail/llvm-dev/2019-March/130788.html
Hi Itaru-san,
IR SVE implementation is ongoing, CC'ing Graham who is leading that effort.
I'm hoping we can have something working before the next release is
branched (Dec/Jan), but I don't expect it to be fully featured (inline
asm, full ACLE, auto-vec in all NEON cases, etc).
cheers,
--renato
Renato et al.
In the meantime, is there an out of tree branch I mean, other than LLVM trunk so I can test how much I can SVE vectorize my code with it?
Arm seemed to gave taken down the GitHub branch for sometime.
Hi Itaru,
(and thanks for the replies on this Renato).
We (Arm HPC) initially put up that github branch as an aid to the discussions on upstream SVE support. The branch was very old (LLVM-5 based!), and various aspects of our implementation have changed significantly, following discussions with the community. For this reason, we felt that branch was unhelpful at this point, so have removed it.
The team are working hard on getting SVE codegen support into LLVM, but it’s not there yet. For now, this leaves the following options for testing vectorization with SVE:
- Get an up to date GNU compiler, which has SVE vectorization support
- Use Arm Compiler for Linux (the new name for Arm Compiler for HPC)
If you’re interested in the latter option, feel free to give me a mail (will.lovett at arm dot com). Depending on your use-case, there may be scope for arranging a license.
Thanks,
Will.
Will,
At RIKEN, we have a licence for the Arm Compiler which produces clean SVE code well, even though that’s based upon
7.1.0, but that’s a reliable toolchain that enables us for gearing up for the FUGAKU supercomputer. However, given Clang trunk is already
in 10 series, lots of good features/enhancements are expected there thus, we’re just wondering whether we are honored to
use the current implementation provided by Arm so we can work together.
Good luck to you Arm folks with the on-going work (with the RISC-V community)! We hope the “Great” merge will happen
sooner than predicted.
Thanks,
Itaru.
Thanks Itaru,
The 20.0 release of our commercial compiler will be based on the LLVM 9 release, so should help slightly there. I’m afraid that producing a public source code release is not on our roadmap, as I believe this would distract our engineering team away from the main upstreaming work.
I do appreciate your enthusiasm here! It should not be too long until we have enough functional infrastructure in place upstream for people outside of Arm to collaborate effectively on it. For now, we’re extremely grateful for code reviews.
Regards,
Will.
Will,
When you guys announce the SVE codegen support is merged in the trunk, hopefully in the near future, that means all of the features/functions
that can currently be found in the current release of Arm Compiler for Linux, correct? We were sitting down this afternoon and wondering about
this a bit thus I am asking.
Hi Itaru,
That’s a slightly complex question. We aim to upstream all codegen improvements, and once base SVE support is upstream we will find it easier to upstream things faster (or, in some cases, develop upstream ‘first’). However, this is a moving target, since we’re actively developing the downstream compiler, so it is likely there will always be a little delta.
Secondly, we have some functionality (such as tuned scalar and vector math and string libraries, or the Fortran frontend), for which the base functionality is available upstream, but is more easily available and tightly integrated in the product.
Finally, we have some functionality (such as our tuned BLAS/Lapack/FFT libraries) which we don’t have any current plans of making available publicly.
Hope that’s helpful,
Will.
Will Lovett
Technical Product Owner
Compilers & Libraries
Arm Allinea Studio
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Itaru-san,
I can't comment on what Arm announces, but upstream LLVM will never
announce "complete support" for any feature. As all other upstream
open source projects, the usage is "as is" and no promises are ever
made.
However, we will *always* be clear of what works, what doesn't and
what we're working on for the future, a process which you are more
than welcome to participate and help us define the roadmap and
implement the features.
There will never be promises of support (there will be bugs, which we
will try our best to fix), nor of delivery (what we work on and what
gets released are two different things).
Furthermore, there is no intention of upstream LLVM to "match" any
downstream toolchain support. Not only there are too many downstream
LLVM-based toolchains (Arm has at least 2) to be practical, but it
would pervert the notion of open source fairness to become a
second-class "product".
We will always strive to have the very best quality of implementation
of the largest set of features we can, while keeping maintenance cost
at the lowest (amortisation of cost in a multi-dimensional space), but
that's a problem that will never be "solved". That's why we keep
trying. 
Regarding upstream SVE support, what I said before is as good guess as
any of what happens next. It will depend on the people upstreaming the
changes, the interaction of those changes with existing code (both
upstream and downstream) as well as feedback from other parts of the
community (ex. RISCV).
My hope is that by the next freeze we'll have enough IR support to
generate some code, but not enough to compile inline asm, ACLE or
automatic vectorisation. Ie. it will be a proof of concept, but hardly
usable.
I think we should prioritise each one of the remaining steps above in
order, so that we can make best use of our time. This is a slow
process, and we should not speed it up artificially, at the expense of
quality and maintainability.
Almost three years ago, when the first email reached the list, I said
this would be at least two years from the first accepted commit and
people called me a pessimist. We've past our first year and there will
be at least another.
For now, use GCC or, if you have access, the Arm compiler. Both
generate good SVE code and show real changes in real benchmarks.
cheers,
--renato