search for: iigir

...ons such as streaming. > > Knowing the number of ways can allow one to guesstimate which memory > accesses are likely to collide in the cache. > > It also happens that all of these parameters are useful for simulation > purposes, which may help projects like llvm-mca. I see. So, IIGIR, initially, this would consolidate the prefetching infrastructure, which is a worthy goal in itself and would require a minimalist implementation for now. But later, vectorisers could use that info, for example, to understand how much would be beneficial to unroll vectorised loops (where total acc...

...be a conscious decision. > Changing vscale would be no different than changing any other value in > the program. The dataflow determines its possible values at various > program points. vscale is an extra (implicit) operand to all vector > operations with scalable type. It is, but IIGIR, changing vscale and predicating are similar transformations to achieve the similar goals, but will not be represented the same way in IR. Also, they're not always interchangeable, so that complicates the IR matching in ISel as well as potential matching in optimisation passes. > Why? If...

...ne is better". > ARM seems to have no difficulty selecting instructions for it. Changing > the value of vscale shouldn't impact ISel at all. The same instructions > are selected. I may very well be getting lost in too many floating future ideas, atm. :) > > It is, but IIGIR, changing vscale and predicating are similar > > transformations to achieve the similar goals, but will not be > > represented the same way in IR. > > They probably will not be represented the same way, though I think they > could be (but probably shouldn't be). Maybe in t...

Hey, I've been reading back the thread and there's a lot of ideas flying around, I may have missed more than I should, but here's my view on it. First, I think this is a good idea. Mapping caches is certainly interesting to general architectures, but particularly important to massive operations like matrix multiply and stencils can pull a lot of data into cache and sometimes thrash

...sub and seriesvector are no longer constant and are likely to be hoisted away from the shufflevector. The knock on effect being to force the code generator into generating generic vector permutes rather than utilise any specialised permute instructions the target provides. The concept looks ok. IIGIR, your argument is that an intrinsic will not look "constant enough" to the other IR passes, which can break the contantness required to generate the correct "constant" vector. I'm also assuming SVE has an instruction that relates to the syntax above, which will reduce the s...

>> The decision of whether or not to include these projects >> affects only read-write consumers of these projects -- of which there >> are relatively few people. > > Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the read-write consumers of the sub-projects being included should count for a lot I agree. > as a read-write

On Mon, 30 Jul 2018 at 20:57, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm not sure exactly how the SVE proposal would address this kind of > operation. SVE uses predication. The physical number of lanes doesn't have to change to have the same effect (alignment, tails). > I think it would be unlikely for anyone to need to change the vector >

...han adding some Instructions to > capture the semantics. I suspect neither would change ISel (I know VL > would not) but as you say I don't think we need concern ourselves with > changing vscale right now, unless others have a dire need to support it. > >>> > It is, but IIGIR, changing vscale and predicating are similar >>> > transformations to achieve the similar goals, but will not be >>> > represented the same way in IR. >>> >>> They probably will not be represented the same way, though I think they >>> could be (but...

On 26 November 2016 at 11:49, Paul Walker <Paul.Walker at arm.com> wrote: > Related to this I want to push this and related conversations in a different direction. From the outset our approach to add SVE support to LLVM IR has been about solving the generic problem of vectorising for an unknown vector length and then extending this to support predication. With this in mind I would