similar to: [LLVMdev] Problems with getelementptr

Displaying 20 results from an estimated 600 matches similar to: "[LLVMdev] Problems with getelementptr"

2004 May 03
0
[LLVMdev] Problems with getelementptr
On Mon, 3 May 2004, Anders Alexandersson wrote: > Hello! > > I'm having trouble with pointer traversing. I have a design as follows: > class -> map -> classFunctions > > Starting with a pointer to the class, I want to get a pointer to a > classFunction via a pointer to the map. Okay... > I can't get that function pointer! > > How shall I think to get
2004 May 11
2
[LLVMdev] Problems accessing structs
Hello! I get some odd behaviour using my structs: "myKernelMap" = type {int (sbyte*)*, int ()*} "Kernel" = type {"myKernelMap"*} The second member ( int()* ) is a pointer to the %getchar() function. I want to call getchar using this function: int "callmyKernelgetchar_kernel"("Kernel"* "myKernel") { "PTRMAP" =
2004 May 11
0
[LLVMdev] Problems accessing structs
Anders Alexandersson wrote: > Hello! > > I get some odd behaviour using my structs: > > "myKernelMap" = type {int (sbyte*)*, int ()*} > "Kernel" = type {"myKernelMap"*} > > The second member ( int()* ) is a pointer to the %getchar() function. > > I want to call getchar using this function: > > int
2004 Apr 02
2
[LLVMdev] Function pointers
OK, I solved it all ( so far :) ), mixing in some load-instructions and called on the result of that, which worked. Here is the skeleton-code: %kernel = type { int ()* } int puts_kernel(){...} ; main() %theKernel = malloc %kernel %puts_kernelPTR = getelementptr %kernel* %theKernel, long 1, ubyte 0 store int ()* %puts_kernel, int ()** %puts_kernelPTR %tmp.11 = load int ()** %puts_kernelPTR
2004 Apr 02
0
[LLVMdev] Function pointers
On Fri, 2 Apr 2004, Anders Alexandersson wrote: > OK, I solved it all ( so far :) ), mixing in some load-instructions and > called on the result of that, which worked. > > Here is the skeleton-code: > > %kernel = type { int ()* } > > int puts_kernel(){...} > > ; main() > > %theKernel = malloc %kernel > %puts_kernelPTR = getelementptr %kernel* %theKernel,
2004 Apr 02
0
[LLVMdev] Function pointers
I solved that one by substituting alloca into malloc, and forwarded the problem to actually calling the %puts_kernel function via my newly created function pointer. This works: %tmp.1 = call int %puts_kernel() This: %tmp.2 = call int %puts_kernelPTR() issues error: "Reference to an invalid definition: 'puts_kernelPTR' of type 'int () *'" How do I call the function
2004 Apr 02
0
[LLVMdev] Function pointers
So, here comes the next question:) Now the program compiles, but crashes when run, "Segmentation fault". %kernel = type { int ()* } int %puts_kernel() { ret int 0 } int %main() { %theKernel = alloca %kernel %puts_kernelPTR = getelementptr %kernel* %theKernel, long 1, ubyte 0 store int ()* %puts_kernel, int ()** %puts_kernelPTR ret int 0 } I want to learn how to
2004 May 05
2
[LLVMdev] Not allowed to reuse variables?
Hello! I am having trouble with identifiers: %tmpFunction = load int ()** %puts_kernelPTR ... %tmpFunction = load int ()** %puts_kernelPTR generates Redefinition of value named 'tmpFunction' in the 'int () *' type plane! Is it not allowed to reuse variables? Is there some way to do it? Anders ---------------------------------------------------------------- Anders
2004 May 05
0
[LLVMdev] Not allowed to reuse variables?
On Wed, May 05, 2004 at 03:35:46PM +0200, Anders Alexandersson wrote: > %tmpFunction = load int ()** %puts_kernelPTR > ... > %tmpFunction = load int ()** %puts_kernelPTR > > generates > > Redefinition of value named 'tmpFunction' in the 'int () *' type plane! > > Is it not allowed to reuse variables? Is there some way to do it? LLVM uses the Static
2005 May 17
4
HOW TO Enable IPSec for FreeBSD.......???
Hi, I have tried to enable IPSec support for my FreeBSD( 4.11-RELEASE) system. First, I copied the generic kernel configuration file to a file I called MYKERNEL: #cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/MYKERNEL Then, I added the following three lines to the options section of /usr/src/sys/i386/conf/MYKERNEL: options IPSEC options IPSEC_ESP options
2014 Mar 23
2
global append changes since version 5
In Syslinux 5-6.02, the "global append" directive is being (unintentionally) ignored in some cases. Updating Syslinux from prior versions, when using a "global append" directive, will cause unexpected results. For example, take the following simple configuration file: *** DEFAULT mykernel APPEND root=/dev/sda2 *** Note that the 'append' line is a global
2007 Mar 01
2
[LLVMdev] Version 1.9 SSA form question
int %nlz10(uint %param.x) { %.t3 = shr uint %param.x, ubyte 1 ; <uint> [#uses=1] %.t4 = or uint %.t3, %param.x ; <uint> [#uses=2] %.t7 = shr uint %.t4, ubyte 2 ; <uint> [#uses=1] %.t8 = or uint %.t7, %.t4 ; <uint> [#uses=2] %.t11 = shr uint %.t8, ubyte 4 ; <uint> [#uses=1]
2002 Sep 25
3
[LLVMdev] question about GetElementPtr Instruction
I have a question about GetElementPtr. Suppose I have an GetElementPtr Instruction GI: %reg = getelementptr %ST* %s, uint 1, ubyte 2, ubyte 1, uint 5, uint 13 I want to check if this is the reference of a component of a structure, how can I do that? Should I check which operand of this instruction is 'ubyte' type? How can I do that in code? should I use ubyte *a =
2006 Mar 16
2
[LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
Hello! I'm compiling code which uses pointers as iterators. For some reason--probably a silly misunderstanding of the docs--I can't eliminate duplicate pointer loads. I'll probably figure this out eventually, but if somebody else sees the answer instantly, I certainly won't complain. :-) Here are the optimizers I'm running: opt -f -simplifycfg -dce -instcombine
2002 Sep 26
2
[LLVMdev] question about GetElementPtr Instruction
You are correct, ubyte 2 simply means 3rd element of the structure. This quantity is always constant (it specifies the field number), so we could have used any signed or unsigned integer type for it instead of ubyte. UByte means we are limited to at most 256 structure fields but it also makes the bytecode representation more compact. (To remove this restriction, we may migrate to UInt in the
2015 Aug 24
4
[PATCH] nv50: avoid using inline vertex data submit when gl_VertexID is used
The hardware only generates vertexid when vertices come from a VBO. This fixes: vertexid-drawelements vertexid-drawarrays Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "11.0" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_program.c | 1 + src/gallium/drivers/nouveau/nv50/nv50_program.h | 1 +
2007 Feb 13
2
[LLVMdev] Unused malloc/free don't get optimized
Hi, i have some code that allocate some memory, store the pointer to a variable, read it back and deallocates it, like this: int %main(int %argc, ubyte** %argv) { %c_19 = alloca ubyte* %malloc_206 = malloc ubyte, uint 10 store ubyte* %malloc_206, ubyte** %c_19 %tmp_207 = load ubyte** %c_19 free ubyte* %tmp_207 ret int 0 } i expected the optimized to remove everything, but after running it the
2007 Jan 14
0
[LLVMdev] Request documentation for global var syntax
On Thu, 11 Jan 2007, Schimmel, Mark wrote: > file://docs/LangRef.html#globalvars > > The section describing the definition of global vars discusses that you > can specify an alignment and can also specify a section. Could someone > provide an example that works in gccas in release 1.9 for both defining > which section the var is assigned to and defining the variables >
2007 Jan 11
3
[LLVMdev] Request documentation for global var syntax
file://docs/LangRef.html#globalvars The section describing the definition of global vars discusses that you can specify an alignment and can also specify a section. Could someone provide an example that works in gccas in release 1.9 for both defining which section the var is assigned to and defining the variables alignment? Also, is there another document that describes how you define sections
2006 Mar 17
0
[LLVMdev] Stupid '-load-vn -licm' question (LLVM 1.6)
On Thu, 16 Mar 2006, Eric Kidd wrote: > Hello! I'm compiling code which uses pointers as iterators. For some > reason--probably a silly misunderstanding of the docs--I can't eliminate > duplicate pointer loads. I'll probably figure this out eventually, but if > somebody else sees the answer instantly, I certainly won't complain. :-) There are no stupid questions.