similar to: [LLVMdev] GetElementPtr.html

Hello, Reading through this, I found a typo... In the paragraph after the 3rd code snippet in the 1st question's section: "The second operand will be the field offset" seems like it should be the third operand? The second is the pointer offset... HTH! =] -Chandler Carruth On 8/15/06, Reid Spencer <rspencer at reidspencer.com> wrote: > > All, > > The often

Hi Aaron, On Sun, 2007-02-18 at 20:43 +0000, Aaron Gray wrote: > Hi Reid, > > Cygwin 'sys/resource.h' has get/setrlimit() functions support for > RLIMIT_DATA and RLIMIT_AS but not RLIMIT_RSS. Then, please fix it to not use RLIMIT_RSS in the cygwin case. Perhaps you should just use RLIMIT_AS for cygwin. It will trigger sooner than RLIMIT_RSS but that's probably okay.

Okay I have put a #ifdef HAVE_RLIMIT_RSS round the RSS code. There needs to be logic added to config system to complement this. Or shall I just use an #ifdef _CYGWIN_ ? Regarding the Bytecode writer stuff. I will try adding some inline dis-ambiguator functions. Aaron ----- Original Message ----- From: "Reid Spencer" <rspencer at reidspencer.com> To: "LLVM Developers

On Mon, 07 Aug 2006 19:36:01 -0700 Reid Spencer <rspencer at reidspencer.com> wrote: > > Hi Simon, > > What version of llvm-gcc did you configure LLVM with? If you don't > know, please send your configure.out file from your LLVM_OBJ_ROOT I didn't find that file in the source anywhere. Also, I don't normally use llvm-gcc, so I didn't knowingly configure for

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 >

Hi Aaaron, On Sun, 2007-02-18 at 19:50 +0000, Aaron Gray wrote: > In order to get Cygwin working there is a need to add a > HAVE_RLIMIT_RSS and associated logic. This was just recently added. Does cygwin even have getrlimit and setrlimit? IIRC correctly, it doesn't. So, perhaps these functions need to be written differently for Cygwin. What's the equivalent win32 call? If cygwin

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

On 3/11/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Could you submit the patch? We could make sure that 2.0 doesn't have the > same problem. Sure, I can't test this from where I am now but if anyone can take it for a spin to test it and verify the fix then by all means check it in. I'm just providing a hand-edited diff from our vendor branch here (1.9 tarball

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 Wed, Jul 22, 2009 at 11:30 AM, Dan Gohman<gohman at apple.com> wrote: >  - The result value of an allocation instruction is associated with >    the address range of the allocated storage. Might want to clarify this to include calloc/realloc. >  - A null pointer is associated with no addresses. A null pointer in address space 0. >  - A pointer value formed by a ptrtoint is

Thanks Ryan, I'm able to retrieved the type using the following code: Type *type=getElementPtrInst->getSourceElementType(); On Fri, Aug 12, 2016 at 7:00 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Take a look at visitGetElementPtrInst in InstructionCombining.cpp for some > examples about how to iterate over GEP and check for type. > >

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

Hi, I found a mysterious behavior of LLVM optimizer. I compiled the following code by clang -emit-llvm -S: #include <stddef.h> static const struct t {char t[4]; char s;} p = {{}, 'a'}; char f() { return ((char*)&p)[offsetof(struct t, s)]; } then I obtained the following LLVM IR: %struct.t = type { [4 x i8], i8 } @p = constant %struct.t { [4 x i8] zeroinitializer, i8 97

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

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Dec 8, 2011 at 11:13 AM Subject: Re: [LLVMdev] GetElementPtr To: Reid Kleckner <reid.kleckner at gmail.com> There is no support for gep, it's my understanding that it's target-independent, so there's no reason to put the lowering in the target lowering portion is there?

Or is it in the docs such that when you use the word "independent", you really mean "independent of a particular target" and not actually "target independent"? On Thu, Dec 8, 2011 at 11:18 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Thu,

Ok, so if I needed very precise control over the allocation of memory, then I should avoid using integers with bit widths larger than 64 bits (or perhaps 128)? Is there a hard rule for an integer being stack allocated, ie. one that doesn't depend on the current implementation details? Sandro On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: > Sandro Magi wrote: > >

On Wed, Dec 7, 2011 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > There is a GEPSplitterPass in the Scalar.h but not in the > LLVM_SRC/lib/Transforms/Scalar folder, there is no GEPSplitterPass.cpp > file. Is it possible to get this from 2.8 and compile it and use it for 2.9? > > > On Wed, Dec 7, 2011 at 12:31 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

On Mon, May 4, 2015 at 9:40 AM, Nicholas White <n.j.white at gmail.com> wrote: > Thanks - that makes sense. It's interesting that at -O3 the optimizer > can't reduce the below though - I'll dig into it a bit and see if I > can make a patch that fixes it: I'm unsure what you expect to happen below. It's not quite the same testcase. GVN will PRE the loads, so you