search for: widen

...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)....

________________________________ 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 n...

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...

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.fitsInLegalInteg...

...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 s...

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target supports 64-bit arithmetics, since the actual NVIDIA GPU typically has only 32-bit integer registe...

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...

Currently, the GVN optimization widens loads if the alignment permits it. There are some limitations that show up, as seen in example below: Initial IR: declare void @consume(i8) readonly define i8 @bar(i8* align 2 %a) { %1 = load i8, i8* %a %idx = getelementptr i8, i8* %a, i64 1 %2 = load i8, i8* %idx, align 1 call void @co...

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 variant would allow the RegAlloc to do an allocation like this W1 = widen-o...

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....

...--- > 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 &...

...atter. The language defines vec3 with the same storage space as vec4 so from a backend perspective they are both the same. I'd really like if I could have LLVM treat vec3 as vec4 but I haven't found out how. Currently the target 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 F...

...> 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....

...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 generat...

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...

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 transf...

...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 sin...

...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) >> >> v3i8 gets widened to v4i8 and then operations get unrolled (scalarized) >>because v4i8 is not a legal type whereas v4i8 gets > >This does not sound right. v3i8 -> v4i8 is okay. But the next step >should be v4i8 -> v4i32. The operation nay be scalarized in the vector >legalization phase....

...xtract_subvector 0x23434a0, 0x23466e0 [ID=0] Split node result: 0x23469e0: v4f32 = extract_subvector 0x23435a0, 0x23466e0 [ID=0] Split node operand: 0x2346be0: v4i1 = setcc 0x23467e0, 0x23469e0, 0x23436a0 [ID=0] Split node result: 0x2348620: v2f32 = extract_subvector 0x23435a0, 0x2346de0 [ID=0] Widen node result 0: 0x2348820: v2i1 = setcc 0x2346ee0, 0x2348620, 0x23436a0 [ID=0] llc: lib/CodeGen/SelectionDAG/LegalizeTypes.h:599: llvm::SDValue llvm::DAGTypeLegalizer::GetWidenedVector(llvm::SDValue): Assertion `WidenedOp.getNode() && "Operand wasn't widened?"' failed. Th...

James, Thanks for your response. I'm working in LLVM 2.7 (I know, it's old) and the default behavior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType(). If my analysis is correct then your v316 STOREs are being broken into multiple ones depending on ARM NEON support. Can you please confirm? Th...