similar to: [LLVMdev] questions

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] questions"

2002 Sep 17
0
[LLVMdev] questions
Also sprach xli3 at uiuc.edu: } Sorry I got really overwhelmed by so many classes and member } functions in LLVM. So would you please clarify some problems } I have? } } 1. If I see this instruction in the function. } } %S.i = alloca %struct.SimpleStruct } } Suppose SimpleStruct is as following: } struct.SimpleStruct = type { int, double } } } When I read the instruction, how can I know the
2005 Mar 08
3
[LLVMdev] Recursive Types using the llvm support library
As far as I can tell, when you construct a type using the support library StructType::get, you have to pass in a list of types. How can you make a Recursive type by passing in a pointer to the type you are constucting. An example where something really simple like the line below was output would be perfect. %struct.linked_list = type { %struct.linked_list*, %sbyte* } Thanks for any help,
2020 Jan 07
3
Best way of implement a fat pointer for C
Dear All, I’m working on a project that extends C. I’m adding a new type of pointer that is a fat pointer. It has some metadata about the pointed object besides the starting address of the object. Currently I implemented this pointer as an llvm:StructType. In llvm::Type generation function llvm::Type *CodeGenTypes::ConvertType(QualType T) in the case for clang::Type::Pointer, instead of creating
2005 Mar 08
0
[LLVMdev] Recursive Types using the llvm support library
On Mon, 7 Mar 2005, John Carrino wrote: > As far as I can tell, when you construct a type using the support > library StructType::get, you have to pass in a list of types. How can > you make a Recursive type by passing in a pointer to the type you are > constucting. > > An example where something really simple like the line below was output > would be perfect. > >
2015 Aug 14
2
[LLVM RFC] Add llvm.typeid.for intrinsic
This is for BPF output. BPF program output bytes to perf through a tracepoint. For decoding such data, we need a way to describe the format of the buffer. This patch is a try which gives each variable a unique number by introducing a new intrinsic 'llvm.typeid.for'. At the bottom is an example of using that intrinsic and the result of $ clang -target bpf -O2 -c -S ./test_typeid.c
2005 Mar 08
2
[LLVMdev] Recursive Types using the llvm support library
>> An example where something really simple like the line below was output >> would be perfect. >> >> %struct.linked_list = type { %struct.linked_list*, %sbyte* } > > Use something like this: > > PATypeHolder StructTy = OpaqueType::get(); > std::vector<const Type*> Elts; > Elts.push_back(PointerType::get(StructTy)); >
2005 Mar 15
2
[LLVMdev] Dynamic Creation of a simple program
Thanks for the information I am trying to use one of your examples for recursive data structures: ========================= PATypeHolder StructTy = OpaqueType::get(); std::vector<const Type*> Elts; Elts.push_back(PointerType::get(StructTy)); Elts.push_back(PointerType::get(Type::SByteTy)); StructType *NewSTy = StructType::get(Elts); // At this point, NewSTy = "{ opaque*, sbyte*
2012 Aug 30
1
How to modify the values of the parameters passing via ...
Dear Friends, Let's assume there are three parameters that were passed into fun1. In fun1, we need to modify one para but the remains need to be untouched. And then all parameters were passed into fun2. However, I have failed to achieve it. Please see the following code. ########################################## fun1 <-function(x, y, z=10) {x+y+z;} fun2 <-function(aa, ...) {
2016 Oct 30
2
RFC: PointerType should derive from Type rather than SequentialType
Hi all, An oddity that has existed for a long time in the IR is that PointerType derives from SequentialType. Per subject I propose to make PointerType derive from Type for a couple of reasons: - Values of type PointerType are unlike the other SequentialTypes (arrays and vectors) in that they do not hold values of the element type. By moving PointerType we can unify certain aspects of how the
2004 Mar 25
1
mlocal/mtrace inside a loop
Hello I need some help in figuring Bravington’s debugger out. Ok I have 2 functions, fun1 and fun2 saved in a ASCII file say filename is funs. Fun1 has a loop which calls fun2, fun2 has a loop which fails and I need to find out the value of the variables of the fun2 and fun1 loops at the specific iteration that fails. Both fun1 and fun2 loops will iterate thousands of times so line by line debug
2006 Aug 09
3
objects and environments
Dear list, I have two functions created in the same environment, fun1 and fun2. fun2 is called by fun1, but fun2 should use an object which is created in fun1 fun1 <- function(x) { ifelse(somecondition, bb <- "o", bb <- "*") ## mymatrix is created, then myresult <- apply(mymatrix, 1, fun2) } fun2 <- function(idx) { if (bb == "o) { #
2005 Mar 15
0
[LLVMdev] Dynamic Creation of a simple program
On Tue, 15 Mar 2005, xavier wrote: > Thanks for the information > I am trying to use one of your examples for recursive data structures: > > ========================= > PATypeHolder StructTy = OpaqueType::get(); > std::vector<const Type*> Elts; > Elts.push_back(PointerType::get(StructTy)); > Elts.push_back(PointerType::get(Type::SByteTy)); > StructType *NewSTy =
2009 Oct 01
1
pass "..." to multiple sub-functions
Dear list, I know I have seen this discussed before but I haven't been successful in searching for "ellipsis", "dots", "..." in the archives. I would like to filter "..." arguments according to their name, and dispatch them to two sub-functions, say fun1 and fun2. I looked at lm() but it seemed more complicated than I need as it modifies the calling
2017 Apr 30
1
`match.call` and dots substitution
I'm noticing some interesting behavior in `match.call` in some corner-ish cases that arise when you try to use `match.call` to match a "grandparent" function and there are dots involved: fun0 <- function(a, ...) fun1(...) fun1 <- function(b, ...) fun2() fun2 <- function() match.call( fun1, sys.call(sys.parent()), expand.dots=FALSE,
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi all, Please review this patch. It's fixing PR3232 comment #8. Function bar from 2008-03-24-BitFiled-And-Alloca.c compiles to: %struct.Key = type { { i32, i32 } } ... define i32 @bar(i64 %key_token2) nounwind { entry: %key_token2_addr = alloca i64 ; <i64*> [#uses=2] %retval = alloca i32 ; <i32*> [#uses=2] %iospec =
2011 Apr 07
2
Two functions as parametrs of a function.
Hi R users: I'm trying to make a function where two of the parameters are functions, but I don't know how to put each set of parameters for each function. What am I missing? I try this code: f2<-function(n=2,nsim=100,fun1=rnorm,par1=list(),fun2=rnorm,par2=list()){ force(fun1) force(fun2) force(n) p1<-unlist(par1) p2<-unlist(par2) force(p1) force(p2)
2012 Nov 20
2
correct function formation in R
Dear list! ? I have question of?'correct function formation'. Which function (fun1 or fun2; see below) is written more correctly? Using ''structure'' as output or creating empty ''data.frame'' and then transform it as output? (fun1 and fun1 is just for illustration). ? Thanks a lot, OV ? code: input <- data.frame(x1 = rnorm(20), x2 = rnorm(20), x3 =
2005 Mar 08
0
[LLVMdev] Recursive Types using the llvm support library
On Tue, 8 Mar 2005, Vladimir Merzliakov wrote: >>> An example where something really simple like the line below was output >>> would be perfect. >>> >>> %struct.linked_list = type { %struct.linked_list*, %sbyte* } >> >> Use something like this: >> >> PATypeHolder StructTy = OpaqueType::get(); >> std::vector<const
2010 Jun 14
2
[LLVMdev] Adding fields in a already built type?
Hi, We build a type with StructType::get(fModule->getContext(), fDspFields, false); with a fDspFields (std::vector<const llvm::Type*> fDspFields;) that is not yet completely known when we have to build the type. It is possible to add fields in a already build type? Thanks Stéphane Letz
2016 Oct 31
2
RFC: PointerType should derive from Type rather than SequentialType
Thanks David. I ended up trying this over the weekend (see https://github.com/llvm-project/llvm-project/compare/ master...pcc:pointertype). It ended up being a net reduction in code size so seems like a useful cleanup even independent of the typeless pointer work, I'll see if I can send a patch to the list. FWIW I think this directly helps towards the migration because we would have a clearer