search for: extracttypeinfo

...tches you haven't posted yet? nope. only loads have special instructions ld_abs/ld_ind which are represented by these intrinsics. stores, so far, are done via single bpf_store_bytes() helper function. > >the typeid changing ids with order is surprising. > >I think the assertion in ExtractTypeInfo() is not hard. > >Just there were no such use cases. May be we can do something > >similar to what LowerIntrinsicCall() does and lower it differently > >in the backend. > > > But in backend can we still get type information? I thought type is > meaningful in frontend o...

...r2, 0 > mov r3, 0 > call llvm.bpf.store.half it didn't work because number and types of args were incompatible. Every samples/bpf/sockex[0-9]_kern.c is using llvm.bpf.load.* intrinsics. the typeid changing ids with order is surprising. I think the assertion in ExtractTypeInfo() is not hard. Just there were no such use cases. May be we can do something similar to what LowerIntrinsicCall() does and lower it differently in the backend.

...>>> each >>> > output >>> > structure we have to define a global varable. >>> >>> why? I think it should work with local pointers as well. >>> >> >> It is defined by LLVM, in lib/CodeGen/Analysis.cpp: >> >> /// ExtractTypeInfo - Returns the type info, possibly bitcast, >> encoded in V. >> GlobalValue *llvm::ExtractTypeInfo(Value *V) { >> ... >> assert((GV || isa<ConstantPointerNull>(V)) && >> "TypeInfo must be a global variable or NULL"); <-- we can...