search for: widening

...other way round: registers can be grouped into super registers). So for instance we've got 16 registers W (as in wide) W0..W15 and 32 registers N (as in narrow) N0..N31. This way, W0 is made by grouping N0 and N1, W1 is N2 and N3, W2 is N4 and N5, ..., W15 is N30 and N31. The target has some widening instructions that take a number of N registers and output a W register. Possible combinations are Wdest = widen-op Nsrc1, Nsrc2 Wdest = widen-op Wsrc1, Nsrc2 The target constraints that the output register of these instructions cannot overlap, physically, an input of a different kind (W vs N). F...

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding metadata and expecting transforms to repect it is a bad idea. It is just too easy for someone who does not...

Dear All, I think adding metadata and expecting transforms to repect it is a bad idea. It is just too easy for someone who does not know about the metadata to add a transform that ignores it. As for SAFECode, I think we have one of several options for handling load-widening. The most obvious one is to have a pass that just boosts the allocation size of any alloca with an align 16 attribute; this pass would only be scheduled to execute when the other SAFECode instrumentation passes are scheduled to execute. Another option would be to just disable the load-widening tr...

Hi, [resurrecting an old mail thread about AddressSanitizer false positive caused by load widening] Once the Attribute::AddressSafety is set by clang (a separate patch), fixing this bug may look as simple as this: --- lib/Analysis/MemoryDependenceAnalysis.cpp (revision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@ !TD.fitsInLegalInteger(...

...All, > > I think adding metadata and expecting transforms to repect it is a bad > idea. It is just too easy for someone who does not know about the metadata > to add a transform that ignores it. > > As for SAFECode, I think we have one of several options for handling > load-widening. The most obvious one is to have a pass that just boosts the > allocation size of any alloca with an align 16 attribute; > This may lead to real bugs being lost (false negatives) > this pass would only be scheduled to execute when the other SAFECode > instrumentation passes are sche...

...s respectively. I haven't looked at other GPU targets such as R600, but I suspect this problem is not restricted to the NVPTX64 target. Below is a reduced example: __attribute__((global)) void foo(int n, int *output) { for (int i = 0; i < n; i += 3) { output[i] = i * i; } } Without widening, the loop body in the PTX (a low-level assembly-like language generated by NVPTX64) is: BB0_2: // =>This Inner Loop Header: Depth=1 mul.lo.s32 %r5, %r6, %r6; st.u32 [%rd4], %r5; add.s32 %r6, %r6, 3; add.s64...

Hi Nadav, I believe the implementation to keep on widening the vector to the next power of two must be in TargetLowering.h because that is where we decide whether to Widen the vector or not, and the size to which we widen it. In this case, we stop at 4xi8 and do not check if it is legal or not. But the comment says ‘try to widen vector elements until a le...

...store i8 0, i8* %a, align 2 %4 = load i16, i16* %0, align 2 <— widened load from bar() %5 = trunc i16 %4 to i8 call void @consume(i8 %5) %6 = icmp ult i16 %4, 256 ret i1 %6 exit: ; preds = %entry ret i1 true } In the absence of GVN widening (we can see this when %a is 1 byte aligned in bar), bar is inlined into foo as-is. Final IR at O3: define i8 @bar(i8* align 1 %a) { %1 = load i8, i8* %a, align 1 <— align is 1, so GVN does not widen load %idx = getelementptr i8, i8* %a, i64 1 %2 = load i8, i8* %idx, align 1 call void...

Hi Quentin, > It sounds like you only need the earlyclobber description for the N, N > variant. > In other words, as long as you use different opcodes for widen-op NN and > widen-op WN, you model exactly what you want. > > What am I missing? > we are using different opcodes for widen-op NN and widen-op WN. My understanding is that not setting earlyclobber to the W, N

On Fri, Dec 16, 2011 at 6:08 PM, Kostya Serebryany <kcc at google.com> wrote: > In this case, we have an array of 22 bytes which is 16-aligned. >> I suspect that load widening changed the alignment of alloca instruction >> to make the transformation legal. Right? >> Can we change the load widening algorithm to also change the size of >> alloca instruction to be dividable by 16? >> This will solve the problem, at least the variant I observe now. &g...

...--- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 6, 2013 3:40:50 PM > Subject: Re: [LLVMdev] Vector splitting vs widening > > Hi Hal, > > > > > > > The problem is essentially the following: there are no vector f32 > types (yet), so the <v4i1> = setcc <v4f32> node needs to be split > and scalarized. The operand splitting seems to start correctly, but > because <...

...has emulated support for vec3 through LLVM. Loads are already widened by LLVM to a vec4. Stores are kind of funny. By default LLVM sets the action to 'widen' but in GenWidenVectorStores what ends up happening is an 2:1 split of the vector that's less efficient in this case than actually widening the vector. The reason is that at this point the call to FindMemType assumes that stores can never be widened to a bigger type and so those types are not considered. The call sequence I'm looking at is WidenVectorOperand() -> WidenVecOp_STORE() -> GenWidenVectorStores() -> FindMemType(...

...> It would be possible but undesirable. > First, asan blows up the IR and running asan early will increase the compile-time. > Second, asan greatly benefits from all optimizations running before it because it needs to instrument less memory accesses. > It actually benefits from load widening too: in the test case above asan instruments only one load instead of two. You certainly wouldn't want to run asan before mem2reg/SRoA, but after that, the benefits are probably small. I'd guess that there is some non-zero value to exposing the code generated by asan to the optimizer. H...

...t would be possible but undesirable. > First, asan blows up the IR and running asan early will increase the > compile-time. > Second, asan greatly benefits from all optimizations running before it > because it needs to instrument less memory accesses. > It actually benefits from load widening too: in the test case above asan > instruments only one load instead of two. > > > You certainly wouldn't want to run asan before mem2reg/SRoA, but after > that, the benefits are probably small. I'd guess that there is some > non-zero value to exposing the code generated...

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from an array of bytes. // P. On Thu, Sep 12, 2019 at 4:22 AM...

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transform...

...mation during this transformation. I didn’t think of atomicity aspect though. Artur > On 28 Sep 2016, at 18:50, Philip Reames <listmail at philipreames.com> wrote: > > There's a bit of additional context worth adding here... > > Up until very recently, we had a form of widening implemented in GVN. We decided to remove this in https://reviews.llvm.org/D24096 precisely because its placement in the pass pipeline was inhibiting other optimizations. There's also a major problem with doing widening at the IR level which is that widening a pair of atomic loads into a single...

Hi Nadav, On 2013-08-12 12:59 PM, "Nadav Rotem" <nrotem at apple.com> wrote: >Hi Paul, > >You can read about it here: >http://blog.llvm.org/2011/12/llvm-31-vector-changes.html > >> Hi, >> >> I am trying to understand how vector type legalization works. In >>particular, I'm looking at i8 vector types on x86 (with sse42 features)

Hello, Working on my (currently out-of-tree) BG/Q PPC enhancements, I've run into the following problem with vector type legalization. Here's a quick example: Scalarize node result 0: 0x2348420: v1f32 = extract_subvector 0x23434a0, 0x2348320 [ID=0] Scalarize node result 0: 0x2348220: v1f32 = extract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 =

...has emulated support for vec3 through LLVM. Loads are already widened by LLVM to a vec4. Stores are kind of funny. By default LLVM sets the action to 'widen' but in GenWidenVectorStores what ends up happening is an 2:1 split of the vector that's less efficient in this case than actually widening the vector. The reason is that at this point the call to FindMemType assumes that stores can never be widened to a bigger type and so those types are not considered. The call sequence I'm looking at is WidenVectorOperand() -> WidenVecOp_STORE() -> GenWidenVectorStores() -> FindMemType(...