search for: widened

Hi all, I'm working on a target whose registers have equal-sized subregisters and all of those subregisters can be named (or the 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

________________________________ 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

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;

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

On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <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 know about the metadata > to add a transform that ignores it. > > As for SAFECode, I think we have one of several options for handling >

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

...include/llvm/Target/TargetLowering.h +++ b/include/llvm/Target/TargetLowering.h @@ -1474,10 +1474,14 @@ public: // Try to widen vector elements until a legal type is found. if (EltVT.isInteger()) { // Vectors with a number of elements that is not a power of two are always - // widened, for example <3 x float> -> <4 x float>. + // widened, for example <3 x i8> -> <4 x i8>. if (!VT.isPow2VectorType()) { NumElts = (unsigned)NextPowerOf2(NumElts); EVT NVT = EVT::getVectorVT(Context, EltVT, NumElts); + while (!isTypeL...

...i16* %2 = load i16, i16* %1, align 2 %3 = trunc i16 %2 to i8 %idx = getelementptr i8, i8* %a, i64 1 %4 = lshr i16 %2, 8 %5 = trunc i16 %4 to i8 call void @consume(i8 %3) ret i8 %5 } define i1 @foo(i8* %a) { entry: %0 = bitcast i8* %a to i16* %1 = load i16, i16* %0, align 2 <— widened load from bar() %2 = trunc i16 %1 to i8 call void @consume(i8 %2) %3 = icmp ult i16 %1, 256 br i1 %3, label %cont.1, label %exit cont.1: ; preds = %entry store i8 0, i8* %a, align 2 %4 = load i16, i16* %0, align 2 <— widened load from bar...

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

...ot;<v2i1> setcc ..." because of the v4f32 operands, > but later on we decide to widen <v2i1> back to <v4i1> because we > legalize the result ? The problem is not the widening itself, but that the widen-result code for setcc assumes that the operands have also just been widened (which here is not true, they've been split instead). FWIW, with the patch I attached, the operands are split, then scalarized, and I'm left with a vector setcc with two build_vector operands. > Can you declare <v2i1> as a legal type ? I'd have to write more load/store code,...

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

On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote: > This is a good question. Would it be possible for ASan to do its instrumentation earlier? > > 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

...d at that at all? > This is the usual phase ordering problem. If asan is done early, you get all of the optimizations cleaning up after asan. If you run asan late, you instrument a cleaner IR. Asan should run after the loop invariant loads are hoisted up, common subexpressions eliminated, loads widened/combined, dead stores eliminated, memsets merged, etc. Otherwise the optimizer will have a hard time optimizing the original code *and* the instrumentation. I have not looked into placing asan somewhere else in LLVM (this is in my TODO list somewhere at the bottom). But I had to place asan early i...

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

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 transformation we agreed > that we don't want to do

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other

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

...23467e0, 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. 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...

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