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