search for: lowleveltypes

I've kicked off a run to compare "-O0 -g" versus "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2". I've selected the test-suite (albeit a version which is a couple of months old now) and a few short-running proprietary benchmarks to get data back quickly for an initial feel of where things are. This was running on Cortex-A57 AArch64 Linux. I saw one assertion

Hi GlobalISel interested parties, A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics. Most of the time, we don’t run into this issue because the generic opcodes distinguish between fp and int operation...

...>> >> A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968 <https://bugs.llvm.org/show_bug.cgi?id=40968>) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics. > > I’m pretty strongly opposed to #2. I think the more relaxed type system is one of the advantages over Sel...

On Thu, Apr 6, 2017 at 6:53 AM, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I've been digging a little bit deeper into the biggest performance > regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving > floating point values through general purpose registers.

Hi Kristof, > On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > I've been digging a little bit deeper into the biggest performance regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving floating point values through general purpose registers. I've

Hi Kristof, > On Apr 27, 2017, at 9:47 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Hi Quentin, > >> On 27 Apr 2017, at 00:48, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Hi Kristof, >> >>> On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com

Hi, GlobalISel, the SelectionDAG replacement, has come a long way since initially discussed on the mailing list and its last discussion at the EuroLLVM BoF (https://etherpad.net/p/GlobalISel <https://etherpad.net/p/GlobalISel>). We believe we are close to the point of enabling it by default on AArch64 at O0. We now would like to enlist your help to get there. *** Quick Status *** On iOS

Great Quentin :). I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm -global-isel -mllvm -global-isel-abort=2" on r302453, on AArch64 Cortex-A57. I indeed see almost no moves between GPR and FPR registers anymore (see details below for where I still see some). On geomean, I see 13% slow down (down from 17% on my previous run). On geomean, code size increase

Hi Quentin, On Tue, May 9, 2017 at 11:47 AM Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kristof, > > On May 9, 2017, at 3:41 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > Great Quentin :). > > I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g -mllvm > -global-isel -mllvm

> On May 9, 2017, at 11:47 AM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Kristof, > >> On May 9, 2017, at 3:41 AM, Kristof Beyls <kristof.beyls at arm.com <mailto:kristof.beyls at arm.com>> wrote: >> >> Great Quentin :). >> >> I've rerun the benchmarks comparing "-O0 -g" with "-O0 -g

In the RISC-V V extension, there is no upper limit to the size vector registers can be in a future CPU. (Formally, the upper limit is at least 2^31 bytes) Generic code can enquire the size, dynamically allocate space, and transparently save and restore the contents of a vector register or registers. On Fri, May 24, 2019 at 11:28 AM JinGu Kang via llvm-dev <llvm-dev at lists.llvm.org>

Hi, Are there any objections to going ahead with this? If not, we'll try to get the patches reviewed and committed after the 7.0 branch occurs. -Graham > On 2 Jul 2018, at 10:53, Graham Hunter <Graham.Hunter at arm.com> wrote: > > Hi, > > I've updated the RFC slightly based on the discussion within the thread, reposted below. Let me know if I've missed

Hi, Now that Sander has committed enough MC support for SVE, here's an updated RFC for variable length vector support with a set of 14 patches (listed at the end) to demonstrate code generation for SVE using the extensions proposed in the RFC. I have some ideas about how to support RISC-V's upcoming extension alongside SVE; I'll send an email with some additional comments on

JinGu: I’m not Graham, but you might find the following link a good starting point. https://community.arm.com/developer/tools-software/hpc/b/hpc-blog/posts/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture The question you ask doesn’t have a short answer. The compiler and the instruction set design work together to allow programs to be compiled without knowing

Hi All, I have read the links from Joel. It seems one of its main focus is vectorization of loop with vector predicate register. I am not sure we need the scalable vector type for it. Let's see a simple example from the white paper. 1 void example01(int *restrict a, const int *b, const int *c, long N) 2 { 3 long i; 4 for (i = 0; i < N; ++i) 5 a[i] = b[i] + c[i]; 6 }

Hi Graham, Thanks for your kind explanation. There was internal discussion about it. If possible, can you let me know the Clang/LLVM CodeGen patches for the vector type on phabricator please? I would like to check what kinds of the restrictions the type causes on Clang/LLVM. Thanks, JinGu Kang ________________________________ From: Graham Hunter <Graham.Hunter at arm.com> Sent: 28 May

On 07/30/2018 05:34 AM, Chandler Carruth wrote: > I strongly suspect that there remains widespread concern with the > direction of this, I know I have them. > > I don't think that many of the people who have that concern have had > time to come back to this RFC and make progress on it, likely because > of other commitments or simply the amount of churn around SVE related >

Hi, i am the main author of RV, the Region Vectorizer (github.com/cdl-saarland/rv). I want to share our standpoint as potential users of the proposed vector-length agnostic IR (RISC-V, ARM SVE). -- support for `llvm.experimental.vector.reduce.*` intrinsics -- RV relies heavily on predicate reductions (`or` and `and` reduction) to tame divergent loops and provide a vector-length agnostic