search for: getorenforceknownalignment

...e a code change ? >> >> >> >> It’s the latter… there’s indeed room to make LV (and SLP) vectorizers >> optimize for larger more efficient alignment, using static analysis and/or >> dynamic peeling/versioning etc. >> >> Cf. LoadStoreVectorizer’s use of getOrEnforceKnownAlignment(). >> >> >> >> Ayal. >> >> >> >> >> >> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Mehdi >> AMINI via llvm-dev >> *Sent:* Thursday, April 12, 2018 01:39 >> *To:* meister at reservoir.com &g...

Hello, I'm playing around with vectorization in LLVM 6.0.0, and I noticed that when creating a vector load out of a scalar load, the alignment for the vector load is defined to be the one of the scalar load. For instance, 16-bit vectors get aligned on 2 bytes. This does not correspond to the preferred alignment for vectors that I specified in the data layout (which is bigger). Inspecting

...Matthijs Index: lib/Transforms/Scalar/InstructionCombining.cpp =================================================================== --- lib/Transforms/Scalar/InstructionCombining.cpp (revision 53716) +++ lib/Transforms/Scalar/InstructionCombining.cpp (working copy) @@ -400,6 +400,8 @@ unsigned GetOrEnforceKnownAlignment(Value *V, unsigned PrefAlign = 0); + /// Propagate address spaces through bitcasts + Instruction *PropagateAddressSpace(BitCastInst &CI); }; } @@ -7841,6 +7843,81 @@ return 0; } +/// Try to propagate the address space from the source...

...nsforms/Scalar/InstructionCombining.cpp > =================================================================== > --- lib/Transforms/Scalar/InstructionCombining.cpp (revision 53716) > +++ lib/Transforms/Scalar/InstructionCombining.cpp (working copy) > @@ -400,6 +400,8 @@ > unsigned GetOrEnforceKnownAlignment(Value *V, > unsigned PrefAlign = 0); > > + /// Propagate address spaces through bitcasts > + Instruction *PropagateAddressSpace(BitCastInst &CI); > }; > } > > @@ -7841,6 +7843,81 @@ > return 0; > } > > +/// Tr...

Hi Eli, Mon Ping, > In ISO/IEC WG14 n1169 on the C extensions to support embedded > processors, any two address spaces must be disjoint, must be > equivalent, or must be nested. Ah, that standard is a lot clearer on this subject than the DSP-C one I read was. > As Eli indicated, the actual relationship is platform specific depending on > what makes the most sense for

In ISO/IEC WG14 n1169 on the C extensions to support embedded processors, any two address spaces must be disjoint, must be equivalent, or must be nested. As Eli indicated, the actual relationship is platform specific depending on what makes the most sense for your hardware and how the program will behave will depend on that relationship. -- Mon Ping On Jul 17, 2008, at 7:25 AM, Eli

I’m taking a first look at InstCombine performance. I picked up the caching patch and ran a few experiments on one of our larger C++ apps. The size of the *.0.2.internalize.bc no-debug IR is ~ 30M. Here are my observations so far. Interestingly, caching produced a slight but measurable performance degradation of -O3 compile time. InstCombine takes about 35% of total execution time, of which ~20%