search for: optforsize

...Of Tom Stellard > Sent: 19 September 2014 01:36 > To: Sanjay Patel > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] predicates vs. requirements [TableGen, > X86InstrInfo.td] > > On Thu, Sep 18, 2014 at 03:25:07PM -0600, Sanjay Patel wrote: > > I tried to add an 'OptForSize' requirement to a pattern in X86InstrSSE.td, > > but it appears to be ignored. However, the condition was detected when > > specified as a predicate. > > > > So this doesn't work: > > def : Pat<(v2f64 (X86VBroadcast (loadf64 addr:$src))), (VMOVDDUPrm >...

I tried to add an 'OptForSize' requirement to a pattern in X86InstrSSE.td, but it appears to be ignored. However, the condition was detected when specified as a predicate. So this doesn't work: def : Pat<(v2f64 (X86VBroadcast (loadf64 addr:$src))), (VMOVDDUPrm addr: $src)>, *Requires<[OptFo...

Thank You. But I cannot find your mentioned function LoopVectorizationCostModel::computeFeasibleMaxVF(bool OptForSize, unsigned ConstTripCount). I am using LLVM 4. I have been trying to get the required code portion in LoopVectorize.cpp file. But I am unable to debug this. each time i debug it, it returns me vectorized IR in gdb. My goal is simple when i mention my target name in opt it should vectorize by keepin...

...ink_once_odr | Weak + | Weak_odr | Appending | Internal + | Private | Dllimport | Dllexport | External_weak | Ghost + | Common + | Linker_private end module Visibility = struct @@ -79,6 +84,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end module Icmp = struct diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli Fri Dec 25 17:35:09 2009 -0800 +++ b/impor...

...that don't support SIMD instructions (for example, standard mips32). > Loop vectorization bloats the code size and prolongs compilation time without any improvement to performance for such targets. > Yes. Also, notice that the loop vectorizer tries to be more conservative when the 'optforsize' attribute is used. Thanks, Nadav

Nadav (or anyone who is familiar with the loop vectorizer), Does the current loop vectorizer inquire about the SIMD capabilities of the target architecture when it decides whether it is profitable to vectorize a loop? I am asking this because I would like to have loop vectorization disabled for targets that don't support SIMD instructions (for example, standard mips32). Loop vectorization

...Private > | Dllimport > | Dllexport > | External_weak > | Ghost > + | Common > + | Linker_private > end > > module Visibility = struct > @@ -79,6 +84,15 @@ > | Nest > | Readnone > | Readonly > + | Noinline > + | Alwaysinline > + | Optforsize > + | Stackprotect > + | Stackprotectreq > + | Nocapture > + | Noredzone > + | Noimplicitfloat > + | Naked > end > > module Icmp = struct > diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.mli > --- a/import/llvm.org/llvm/bindings/ocaml/llvm...

On Sun, Feb 27, 2011 at 01:29:25AM +0100, Joerg Sonnenberger wrote: > +let Predicates = [OptForSize] in { > +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; > +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; > +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8 addr:$dst, -1)>; > +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8 addr:$d...

On Sat, Feb 26, 2011 at 02:04:54PM -0800, Jakob Stoklund Olesen wrote: > > On Feb 26, 2011, at 1:36 PM, Joerg Sonnenberger wrote: > > > On Sat, Feb 26, 2011 at 01:07:39PM -0800, Jakob Stoklund Olesen wrote: > >> > >> You may want to consider using xorl+decl instead. It is also three > >> bytes, and there are no false dependencies. The xor idiom is

...in cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for certain cases. > > I've attached a potential fix for the 2.8 branch. > > The real problem is that the code above it which checks for > isUNPCK[L|H]_v_undef_Mask cases is only for when OptForSize is true. It > assumes that otherwise things can get lowered to PSHUFD (which is true for > v4i32 and v4f32 but nothing else - in particular MMX operations). > > I'll file a bug now... > > Nicolas > > > -----Original Message----- > From: Dale Johannesen [mailto:dale...

...ructions (for example, > standard mips32). > > Loop vectorization bloats the code size and prolongs compilation time > without any improvement to performance for such targets. > > > > Yes. Also, notice that the loop vectorizer tries to be more conservative > when the 'optforsize' attribute is used. > Isn't the vectorizer disabled by default? Or are you requesting that if the user chooses -vectorize the compiler prints a warning (unused param since no SIMD)? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

...Please help. On Mon, Jul 23, 2018 at 11:33 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 7/23/2018 10:49 AM, hameeza ahmed via llvm-dev wrote: > > Thank You. > > But I cannot find your mentioned function LoopVectorizationCostModel::computeFeasibleMaxVF(bool > OptForSize, unsigned ConstTripCount). I am using LLVM 4. > > > "git log -ScomputeFeasibleMaxVF" says this was refactored in > https://reviews.llvm.org/rL297737 . > > -Eli > > -- > Employee of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a membe...

...ructions (for example, standard > mips32). > > Loop vectorization bloats the code size and prolongs compilation time > without any improvement to performance for such targets. > > > > Yes. Also, notice that the loop vectorizer tries to be more conservative > when the 'optforsize' attribute is used. > > > Thanks, > Nadav > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130103/94206511/attachment.html>

On Feb 26, 2011, at 4:50 PM, Joerg Sonnenberger wrote: > On Sun, Feb 27, 2011 at 01:29:25AM +0100, Joerg Sonnenberger wrote: >> +let Predicates = [OptForSize] in { >> +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; >> +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; >> +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8 addr:$dst, -1)>; >> +def : Pat<(store (i64 -1), addr:$dst),...

On Sep 21, 2010, at 5:30 PMPDT, Bill Wendling wrote: > LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. > > -bw Right, early on there

...f --git a/lib/Transforms/Vectorize/LoopVectorize.cpp b/lib/Transforms/Vectorize/LoopVectorize.cpp index 7867495..978c5a1 100644 --- a/lib/Transforms/Vectorize/LoopVectorize.cpp +++ b/lib/Transforms/Vectorize/LoopVectorize.cpp @@ -5142,8 +5142,8 @@ LoopVectorizationCostModel::selectUnrollFactor(bool OptForSize, // fit without causing spills. All of this is rounded down if necessary to be // a power of two. We want power of two unroll factors to simplify any // addressing operations or alignment considerations. - unsigned UF = PowerOf2Floor((TargetNumRegisters - R.LoopInvariantRegs) / -...

On 16/01/2014, 23:47 , Andrew Trick wrote: > > On Jan 15, 2014, at 4:13 PM, Diego Novillo <dnovillo at google.com > <mailto:dnovillo at google.com>> wrote: > >> Chandler also pointed me at the vectorizer, which has its own >> unroller. However, the vectorizer only unrolls enough to serve the >> target, it's not as general as the runtime-triggered