search for: isvoid

...stomOpParams>; def : Pat<(customop tglobaladdr:$dst,iPTR:$vararg), (int_tce_customop tglobaladdr:$dst, iAny:$vararg)>; def : Pat<(call texternalsym:$dst,iAny:$vararg), (int_tce_customop texternalsym:$dst, iAny:$vararg)>; but compilation gives following error: isVoid:void anonymous.52: (intrinsic_void:void 197:iPTR, (tglobaladdr:iPTR):$dst, isVoid:void) /home/elhigu/llvm-install/llvm/Release/bin/tblgen: In anonymous.52: Type inference contradiction found in node! Mikael Lepistö

...with {}. Void is a weird type in >> that it is only allowed as the return value of functions and as the type of >> instructions like store. It seems better (though also not particularly >> high priority) to eliminate it to make the type system more consistent. >> > MVT::isVoid and Type::VoidTyID (getVoidTy) have equivalent relation in LLVM. I am wondering to know whether the relation becomes MVT::isVoid corresponding to { } If eliminating void type? Thanks a lot Mitnick -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ll...

...e (v8f32 undef), (v8f32 VR256:$src1), VEXTRACTF128_shuffle_mask:$src2)))]>; (This is simplified for the sake of exposition but this gets the idea across). TableGen reports a type contradition: VEXTRACTF128_256mri: (st:isVoid (vector_shuffle:v4f32 (undef:v8f32), VR256:v8f32:$src1, (build_vector)<<P:Predicate_VEXTRACTF128_shuffle_mask>>: $src2), addr:iPTR: $dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>> tblgen: In VEXTRACTF128_256mri: T...

.... It's a big improvement over the old system and provides the context that code generation for AVX needs. This is great! I'm asking because I'm having some trouble converting some AVX patterns over to the new system. I'm getting this error from tblgen: VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) llvm/lib/Target/X86/X86...

...ic<[llvm_anyfloat_ty,llvm_i32_ty,llvm_i32_ty],[IntrWriteMem],"llvm.migrate_end_float">;<br><br>I am not able to handle all of the pointer return type instructions.<br><br>I tried using the types such as:<br><br>def llvm_vararg_ty : LLVMType<isVoid>; // this means vararg here<br>def llvm_iPTR_ty : LLVMType<iPTR><br>def llvm_descriptor_ty : LLVMPointerType<llvm_empty_ty>; <br>and adding types<br>def llvm_ptriAny_ty : LLVMPointerType<llvm_anyint_ty>; <br>def llvm_ptrfAn...

Can someone explain why TableGen can't figure this out? VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! The pattern as written looks like this: [(set VR128:$dst, (v4f32 (sint_to_fp (bc_memopv4i32 addr:$src))))] I&...

In order to make metadata useful to the backend, I'd like to permit intrinsics to be written that take metadata-typed objects. To allow this, I decided to try adding a new machine value type right next to isVoid. I updated both ValueTypes.td and ValueTypes.h as well as TableGen/IntrinsicEmitter.cpp and TableGen/CodeGenTarget.cpp where they have switch(mvt). The actual patch is attached. This runs into trouble with the X86 backend where the SSE2 forms of ADD are defined: llvm[3]: Building X86.td DAG i...

Can anyone puzzle out what tblgen is trying to tell me here? VR256:v32i8:$src MD0.VMOVDQA_256mr: (st:isVoid VR256:v32i8:$src, addr:iPTR: $dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>> /ptmp/dag/universal_build/debug/DEFAULT/llvm/tblgen: In MD0.VMOVDQA_256mr: Type inference contradiction found in node! I don't see any type con...

David Greene <dag at cray.com> writes: > I'm asking because I'm having some trouble converting some AVX patterns > over to the new system. I'm getting this error from tblgen: > > VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) > llvm/lib/Target/X8...

Hello Chris, The general concept is to replace void with {}. Void is a weird type in > that it is only allowed as the return value of functions and as the type of > instructions like store. It seems better (though also not particularly > high priority) to eliminate it to make the type system more consistent. > > -Chris > I also noticed a sentence "We can even make

On Apr 22, 2012, at 3:44 AM, Lyu Mitnick wrote: > Hello Chris, > > The general concept is to replace void with {}. Void is a weird type in that it is only allowed as the return value of functions and as the type of instructions like store. It seems better (though also not particularly high priority) to eliminate it to make the type system more consistent. > > -Chris > >

...oat : > Intrinsic<[llvm_anyfloat_ty,llvm_i32_ty,llvm_i32_ty], > [IntrWriteMem],"llvm.migrate_end_float">; > > I am not able to handle all of the pointer return type instructions. > > I tried using the types such as: > > def llvm_vararg_ty : LLVMType<isVoid>; // this means vararg here > def llvm_iPTR_ty : LLVMType<iPTR> > def llvm_descriptor_ty : LLVMPointerType<llvm_empty_ty>; > and adding types > def llvm_ptriAny_ty : LLVMPointerType<llvm_anyint_ty>; > def llvm_ptrfAny_ty : LLVMPointerType<llvm_a...

How is bc_memopv4i32 defined? The bitconvert in the tablegen output is marked isInt, which means it's the node that didn't get inferred. Dan On Jun 4, 2009, at 1:06 PM, David Greene wrote: > Can someone explain why TableGen can't figure this out? > > VCVTDQ2PS128rm: (set:isVoid VR128:v4f32:$dst, (sint_to_fp:v4f32 > (bitconvert:isInt (ld:v4i32 addr:iPTR:$src)<<P:Predicate_memop>>))) > llvm/tblgen: In VCVTDQ2PS128rm: Could not infer all types in pattern! > > The pattern as written looks like this: > > [(set VR128:$dst, (v4f32 (sint_to_fp (bc_me...

...      (v8f32 undef), (v8f32 VR256:$src1), >                                     VEXTRACTF128_shuffle_mask:$src2)))]>; > > (This is simplified for the sake of exposition but this gets the idea across). > > TableGen reports a type contradition: > > VEXTRACTF128_256mri:    (st:isVoid (vector_shuffle:v4f32 (undef:v8f32), > VR256:v8f32:$src1, (build_vector)<<P:Predicate_VEXTRACTF128_shuffle_mask>>: > $src2), addr:iPTR: > $dst)<<P:Predicate_unindexedstore>><<P:Predicate_store>><<P:Predicate_alignedstore>> > tblgen: In VEX...

...;greened at obbligato.org> wrote: > David Greene <dag at cray.com> writes: > >> I'm asking because I'm having some trouble converting some AVX patterns >> over to the new system.  I'm getting this error from tblgen: >> >> VyPERM2F128PDirrmi:   (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64 addr:iPTR:$src2)<<P:Predicate_unindexedload>><<P:Predicate_load>><<P:Predicate_memop>>)<<P:Predicate_vperm2f128>><<X:SHUFFLE_get_vperm2f128_imm>>) >> llvm/lib/Targe...

...al concept is to replace void with {}. Void is a weird type in that it is only allowed as the return value of functions and as the type of instructions like store. It seems better (though also not particularly high priority) to eliminate it to make the type system more consistent. > > MVT::isVoid MVT is separate from the LLVM IR type system, I would not change it. > and Type::VoidTyID VoidTyID should go away, since there is no more distinct Void type anymore. > (getVoidTy) have equivalent relation in LLVM. For API continuity, Type::getVoidTy() should still exist, but it should r...

...T.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) || getOperationAction(Op, NVT) == Promote); The first line in the do while loop is important, it just increments the type, starting at MVT::v4i8 until it hits a legal type. This...

...T.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && "Didn't find type to promote to!"); } while (!isTypeLegal(NVT) || getOperationAction(Op, NVT) == Promote); The first line in the do while loop is important, it just increments the type, starting at MVT::v4i8 until it hits a legal type. This...

...()) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { > NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); > assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && > "Didn't find type to promote to!"); > } while (!isTypeLegal(NVT) || > getOperationAction(Op, NVT) == Promote); > > The first line in the do while loop is important, it just increments > the type, starting at MVT::v4i8 unti...

...)) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { > NVT = (MVT::SimpleValueType)(NVT.getSimpleVT().SimpleTy+1); > assert(NVT.isInteger() == VT.isInteger() && NVT != MVT::isVoid && > "Didn't find type to promote to!"); > } while (!isTypeLegal(NVT) || > getOperationAction(Op, NVT) == Promote); > > The first line in the do while loop is important, it just increments > the type, starting at MVT::v4i8 unt...