similar to: [LLVMdev] predicates vs. requirements [TableGen, X86InstrInfo.td]

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf 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: >

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

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

Hi Akira! > > 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? Yes, it uses a cost model to determine the profitability of vectorization. At the moment only x86 provides the necessary hooks that are needed for calculating the costs. We may need to change the cost defaults to

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

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B

Hello, I did as you said, Please tell me whether the following correct now?? def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, _.KRCWM:$mask_wb), (VR_2048:$src1, _.KRCWM:$mask, ins i2048mem:$src2), "GATHER_256B\t{$src2, {$dst}{${mask}}|${dst} {${mask}}, $src2}"), [(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode

Thank You. Still getting errors.I have modified my instructions as you said as follows: def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, VK64WM:$mask_wb), (ins VR_2048:$src1, VK64WM:$mask, i2048mem:$src2), "GATHER_256B\t{$src2, {$dst} {${mask}}|${dst} {${mask}}, $src2}", [(set VR_2048:$dst, VK64WM:$mask_wb, (v64i32 (masked_gather

Not sure who owns this bit of code, so sending this to the general list. It looks like there may be an unintentional fall through happening in the X86RegisterInfo::getCallPreservedMask function. http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html case CallingConv::Intel_OCL_BI

Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: >

This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from floating point additions and subtractions of appropriate vector shuffles. To do this I introduced new x86 FHADD and FHSUB opcodes. These need to be wired up somehow in the .td file to the appropriate instructions. Since I have no idea how tablegen works I just hacked it in horribly. It works, but breaks support for the hadd

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

> That's far more worrying to me than not being able to detect Haswell. > I can't reproduce the problem here at the moment: both debug and > release builds give identical assembly for Host.cpp. OK. I know the reason you cannot reproduce it, before posting the patch I've decided to check for AVX before checking AVX2, just not to cpuid AVX2 when we don't have AVX1 anyway.

On Friday 03 October 2008 12:06, Dan Gohman wrote: > On Fri, October 3, 2008 9:10 am, David Greene wrote: > > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection > >> loads have multiple uses, so even though you've managed to match a > >> larger pattern that incorporates them, they

On Oct 6, 2011, at 7:59 AM, David A. Greene wrote: > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, >

Hi Duncan, On Wed, Sep 21, 2011 at 1:24 PM, Duncan Sands <baldrick at free.fr> wrote: > This patch synthesizes haddps/haddpd/hsubps/hsubpd instructions from > floating > point additions and subtractions of appropriate vector shuffles.  To do this > I > introduced new x86 FHADD and FHSUB opcodes.  These need to be wired up > somehow > in the .td file to the appropriate

> I promise I'll do the review of your code after that. Tim, I don’t want to push too much. But since there’s 3.4 release on the horizon, maybe you could find a moment review this patch. Especially Haswell is all there since few months. Cheers, -- Adam --- lib/Support/Host.cpp | 8 ++++++++ lib/Target/X86/X86Subtarget.cpp | 3 ++- 2 files changed, 10 insertions(+), 1

Hi Adam, > OK. I know the reason you cannot reproduce it, before posting > the patch I've decided to check for AVX before checking AVX2, > just not to cpuid AVX2 when we don't have AVX1 anyway. I suspect it was also incompetence on my part. Given the differences I'm seeing now I can't believe there'd be *no* difference in my tests if I'd done them properly.

Assign the bug to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for

The output of the avx-hadd program is 3 11 7 15 Preston -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Duncan Sands Sent: Thursday, September 22, 2011 3:14 PM To: Bruno Cardoso Lopes Cc: LLVMdev Subject: Re: [LLVMdev] Patch to synthesize x86 hadd instructions; need help with the tablegen bits Hi Bruno, > Some comments: