search for: llvm_i64_ty

Hello, I have a problem with pattern matching on intrinsics. I have following code in IntrinsicsX86.td: ``` let TargetPrefix = "x86" in { // All intrinsics start with "llvm.x86.". def int_x86_mpx_bndmk: Intrinsic<[llvm_x86bnd_ty], [llvm_ptr_ty, llvm_i64_ty], []>; } ``` And following instruction that is generated when @llvm.x86.mpx.bndmk is used in code: ``` let isPseudo = 1 in let usesCustomInserter = 1 in def BNDMK64rm_Int: PseudoI<(outs BNDR:$dst), (ins i64mem:$src, GR64:$shift), [(set BNDR:$dst, (int_x86_mpx_bndmk addr:$src, i64:$shif...

...oad operations that were deleted by InstCombine, please note that once the load was removed there is no way to restore it back and that prevents us from vectorizing the shuffle operation. There are probably more similar issues where this approach could be applied. I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, indicating that for particular pointer let's call it %ptr we observed maximum possible offset at which there was reference by its type in a function. After InstCombine deleted the load operation, it could be restored in SLPVectorizer and we could restore chains of GEPs, Loa...

...were deleted by InstCombine, please note that > once the load was removed there is no way to restore it back and that > prevents us from vectorizing the shuffle operation. There are probably > more similar issues where this approach could be applied. > I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, > indicating that for particular pointer let's call it %ptr we observed > maximum possible offset at which there was reference by its type in a > function. After InstCombine deleted the load operation, it could be > restored in SLPVectorizer and we could restore...

...2_32_32 : GCCBuiltin<"__builtin_ia32_crc32si">, > Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], > [IntrNoMem]>; > - def int_x86_sse42_crc64_8 : > + def int_x86_sse42_crc32_64_8 : > Intrinsic<[llvm_i64_ty], [llvm_i64_ty, llvm_i8_ty], > [IntrNoMem]>; > - def int_x86_sse42_crc64_64 : GCCBuiltin<"__builtin_ia32_crc32di">, > + def int_x86_sse42_crc32_64_64 : GCCBuiltin<"__builtin_ia32_crc32di">, > Intrinsic<[l...

...auses the Verifier to fail with: Intrinsic name not mangled correctly for type arguments! Should be: llvm.foobar.i64 It seems to me the problem occurs when the return type is overloaded. If I change the return type for the intrinsic in Intrinsics.td from llvm_anyint_ty to a specific type, say llvm_i64_ty, then it works without any issues. Is this a limitation or a bug in the verifier or builder? Should I explicitly create a declaration for the intrinsic for each return type, before calling IRBuilder::CreateIntrinsic? I haven't checked it if it would work in my code (but writing it like that...

...obalISel.inc:11582:60: error: ‘idaho_mt_begin’ is not a member of ‘llvm::Intrinsic’ GIM_CheckIntrinsicID, /*MI*/0, /*Op*/0, Intrinsic::idaho_mt_begin, This intrinsic is defined pretty simply: let TargetPrefix = "idaho" in { def int_idaho_mt_begin : Intrinsic<[], [llvm_ptr_ty,llvm_i64_ty], []>; } With LLVM 7, I notice that build/include/llvm/IntrinsicEnums.inc contains an entry for each intrinsic in the system. This is no longer the case for LLVM 10: there are only 277 definitions in the file. It seems that LLVM 10 imposes some filter condition where it deems inclusion in the...

I have a question about the SSE scalar convert intrinsics. cvtsd2si is defined thusly: def int_x86_sse2_cvtsd2si64 : GCCBuiltin<"__builtin_ia32_cvtsd2si64">, Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; This matches the signature of the GCC intrinsic. The fact that the GCC intrinsic has a type mismatch on the input (vector rather than scalar) is strange, but ok, we'll run with it. Until this: def Int_CVTSD2SIrm : SDI<0x2D, MRMSrcMem, (outs GR32:$dst), (...

...ase note that >>> once the load was removed there is no way to restore it back and that >>> prevents us from vectorizing the shuffle operation. There are probably >>> more similar issues where this approach could be applied. >>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>> indicating that for particular pointer let's call it %ptr we observed >>> maximum possible offset at which there was reference by its type in a >>> function. After InstCombine deleted the load operation, it could be >>> restored in SL...

...t;>>> once the load was removed there is no way to restore it back and that >>>> prevents us from vectorizing the shuffle operation. There are probably >>>> more similar issues where this approach could be applied. >>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>> indicating that for particular pointer let's call it %ptr we observed >>>> maximum possible offset at which there was reference by its type in a >>>> function. After InstCombine deleted the load operation, it could be >>>&gt...

On Jun 5, 2009, at 8:51 AM, David Greene wrote: > I have a question about the SSE scalar convert intrinsics. > > cvtsd2si is defined thusly: > > def int_x86_sse2_cvtsd2si64 : > GCCBuiltin<"__builtin_ia32_cvtsd2si64">, > Intrinsic<[llvm_i64_ty, llvm_v2f64_ty], [IntrNoMem]>; > > This matches the signature of the GCC intrinsic. The fact that the > GCC > intrinsic has a type mismatch on the input (vector rather than scalar) > is strange, but ok, we'll run with it. > > Until this: > > def Int_CVTSD2SIrm :...

...t; once the load was removed there is no way to restore it back and that >>>>> prevents us from vectorizing the shuffle operation. There are probably >>>>> more similar issues where this approach could be applied. >>>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>>> indicating that for particular pointer let's call it %ptr we observed >>>>> maximum possible offset at which there was reference by its type in a >>>>> function. After InstCombine deleted the load operation, it could be &gt...

...load was removed there is no way to restore it back and that >>>>>> prevents us from vectorizing the shuffle operation. There are probably >>>>>> more similar issues where this approach could be applied. >>>>>> I added phatom_mem(llvm_anyptr_ty, llvm_i64_ty) intrinsic for that, >>>>>> indicating that for particular pointer let's call it %ptr we observed >>>>>> maximum possible offset at which there was reference by its type in a >>>>>> function. After InstCombine deleted the load operation, it...

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

...LVMEmptyStructType + : LLVMType<OtherVT, "Type::StructTyID">{ +} + def llvm_void_ty : LLVMType<isVoid, "Type::VoidTyID">; def llvm_bool_ty : LLVMIntegerType<i1, 1>; def llvm_i8_ty : LLVMIntegerType<i8 , 8>; @@ -76,9 +85,10 @@ def llvm_i64_ty : LLVMIntegerType<i64, 64>; def llvm_float_ty : LLVMType<f32, "Type::FloatTyID">; def llvm_double_ty : LLVMType<f64, "Type::DoubleTyID">; -def llvm_ptr_ty : LLVMType<iPTR, "Type::PointerTyID">; // i8* -def llvm_ptrpt...

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

...a/include/llvm/IR/Intrinsics.td +++ b/include/llvm/IR/Intrinsics.td @@ -640,6 +640,7 @@ def int_masked_scatter: Intrinsic<[], def int_bitset_test : Intrinsic<[llvm_i1_ty], [llvm_ptr_ty, llvm_metadata_ty], [IntrNoMem]>; +def int_typeid_for : Intrinsic<[llvm_i64_ty], [llvm_any_ty], [IntrNoMem]>; //===----------------------------------------------------------------------===// // Target-specific intrinsics //===----------------------------------------------------------------------===// diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp b/lib/Co...

On 2015/8/12 12:57, Alexei Starovoitov wrote: > On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote: >> Think about a program like this: >> >> struct strA { int a; } >> struct strB { int b; } >> int func() { >> struct strA a; >> struct strB b; >> >> a.a = 1; >> b.b = 2; >>