similar to: [LLVMdev] A question about getElementPtr

Ram: Let me explain and hopefully Reid or Chris will correct if I have it wrong. The first 0 is the index into a possible array of sbyte[13] arrays that this pointer points to. I expect GetElementPtr works this way is to keep down the proliferation of arrays of arrays in the type table. So you are pointing at the zeroth, and in this case only, array of sbyte[13]. The next 0 actually

I am trying to understand the hello word assember example. This is my version: %str1 = internal constant [13 x sbyte] c"Hello World\0a\00" declare int %printf(sbyte*, ...) implementation ; Functions: int %main() { %str2 = getelementptr [13 x sbyte]* %str1, long 0, long 0 call int(sbyte*, ...) *%printf(sbyte* %str2) ret int 0 } Why is getelementptr being given two "long

At 09:37 PM 8/23/2004, you wrote: >On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > > At 06:43 PM 8/20/2004, Chris Lattner wrote: > > >I don't understand what you're getting at here. You can change char to > > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > > >understand how that would change anything to be more useful

At 05:09 PM 8/20/2004, you wrote: >On Fri, 20 Aug 2004, Reid Spencer wrote: > > > defined would be almost always stored in one byte instead of the present > > > usual two. > > > > So, if I get you correctly, you're advocating the creation of a > Type::CharTyID > > in the TypeID enumeration that is always written as a single byte? Note > that >

On Mon, 2004-08-23 at 19:46, Robert Mykland wrote: > At 06:43 PM 8/20/2004, Chris Lattner wrote: > >I don't understand what you're getting at here. You can change char to > >default to unsigned right now with llvm-gcc -funsigned-char. I don't > >understand how that would change anything to be more useful though. > > Well, in the old days, char strings were

On Fri, 20 Aug 2004, Reid Spencer wrote: > > defined would be almost always stored in one byte instead of the present > > usual two. > > So, if I get you correctly, you're advocating the creation of a Type::CharTyID > in the TypeID enumeration that is always written as a single byte? Note that > right now all ASCII values ( <128 ) will be written as a single byte for

Dear Chris et al, James Weisner and I would like to attend your conference on the 25th. We will have to get up earlier than we tend to so we can make it there from Santa Cruz by 8 AM! See you there! By the way, we reached a major milestone last Friday. We can now turn pretty much anything reasonably simple that can be compiled by LLVM into one giant "virtual" combinatorial

On Fri, 2004-08-20 at 17:55, Robert Mykland wrote: > At 05:09 PM 8/20/2004, Chris Lattner wrote: > > > >If you're interested in the plans, they are described in some detail here: > >http://nondot.org/sabre/LLVMNotes/TypeSystemChanges.txt > > > >Note that there is no concrete timeline for this to happen, it basically > >depends on when someone is ambitious

Hi All, I was wondering if there is an optimisation pass that moves a stack allocated array, initialised with constant values, to a global constant array. And if there is such a pass, what requirements are there for it to operate? My optimised IR is below. As you can see an array of 5 integers is created with alloca, then each element is stored to in turn. It would be nice if this array was

Hi, I want to print the memory locations computed by getelementptr. As I understood, getelementptr does not access the memory, but it contains the address it computes. I want to print these addresses at runtime (or process them). So, I try to build a function that takes as argument a pointer and prints its value. And to call this function, by sending the gep instruction as a parameter.

All, The often misunderstood GetElementPtr (GEP) instruction now has its own FAQ document. For all of you that have struggled with understanding how this instruction works, hopefully this document will make it clear and help you with your use of LLVM. Many thanks to Chris Lattner for setting me straight on how this instruction works and reviewing the document. Document Link :

On 7/20/11 10:02 AM, Jimborean Alexandra wrote: > Hi, > > I want to print the memory locations computed by getelementptr. As I > understood, getelementptr does not access the memory, but it contains > the address it computes. I want to print these addresses at runtime > (or process them). So, I try to build a function that takes as > argument a pointer and prints its

On 2009-07-22 21:30, Dan Gohman wrote: > Hello, > > I'm working on refining the definition of getelementptr (GEP) to > clarify its semantics and to allow front-ends to provide additional > information to optimization passes. > > To help support this, I'd like to propose the following rule: > > Any memory access must be done though a pointer value associated >

Hello, I wonder if the getelementptr can have other successors than load, store in some other cases when I directly print or directly return the result. every time I would like to assign the result - it will have a load/store successor? So, basically the overall question is to clarify the possible successors of getelementptr. -------------- next part -------------- An HTML attachment was

Ok, thank you. I have also one question about getelementptr. In different versions of clang I see that sometimes array[i][i] is preceded by two getelementptr instructions and sometimes only by one - with an already complex index. 2017-09-01 12:50 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On 1 Sep 2017, at 11:44, Anastasiya Ruzhanskaya via llvm-dev < > llvm-dev

I got a little problems with strings (const char pointers). Global variables holding the string literal are declared correctly, but i have a problem when I pass this string to a function: it asserts with this message. Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"), function

On Jul 22, 2009, at 1:28 PM, Török Edwin wrote: > On 2009-07-22 21:30, Dan Gohman wrote: > >> Hello, >> >> >> >> I'm working on refining the definition of getelementptr (GEP) to >> >> clarify its semantics and to allow front-ends to provide additional >> >> information to optimization passes. >> >> >> >> To

Hi Gavin, Do you mean something along the lines of having my array struct as { i32, i32* } and then indexing it with a gep and allocating the appropriate memory when I learn of it? Thanks, Fraser Gavin Harrison-2 wrote: > > Hi Fraser, > > Is there anything preventing you from using a pointer for the second part > of the structure and allocating memory for it later? > >

No. It would be helpful to understand what you are trying to accomplish overall, which may help people give you details about the best way to accomplish it. For example, if you are trying to understand or recover array indexes from GEP's, that is non-trivial. On Sat, Sep 2, 2017 at 3:53 AM, Anastasiya Ruzhanskaya via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Is there a way

Hi Robert, Please make sure that you: 1. Completely rebuild LLVM (make clean; make reconfigure; make tools-only) 2. Completely rebuild llvm-gcc (wipe out the build dir with rm -rf, configure llvm-gcc and rebuild it) If you've done that, then please enter the debugger and get a stack trace for us. You will need to: 1. Capture the xgcc compile command that failed 2. Run that command