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

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

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

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

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 >

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, 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 :

At 02:05 PM 8/20/2004, you wrote: >Robert Mykland wrote: >>Dear Chris and Reid: > >Hi Robert. > >>Some other random ideas I've had as I've been sifting through the new >>bytecode format. Please let me know what you think. >>1) ANSI C allows for char to default to unsigned char. This is I guess >>not how it normally is in GCC. If char defaulted

Dear Chris and Reid: Some other random ideas I've had as I've been sifting through the new bytecode format. Please let me know what you think. 1) ANSI C allows for char to default to unsigned char. This is I guess not how it normally is in GCC. If char defaulted to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

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

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

Reid, Thanks for the detailed feedback. A value of zero now means zero literal for everything except labels, right? There is kind of a vague reference to this in the 1.0 -> 1.1 section I believe. You might want to make this clearer when talking about values in the body of the document. --> A comment on this: if a value of zero were never used for labels, that would make me happy,

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