search for: i_load

In the insrtuction %1 = load i32** %y_addr, align 4 what is the meaning of align 4?? Can anyone explain? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100716/ef433d43/attachment.html>

> In the insrtuction > %1 = load i32** %y_addr, align 4 > what is the meaning of align 4?? > Can anyone explain? >From http://llvm.org/docs/LangRef.html#i_load : "The optional constant align argument specifies the alignment of the operation (that is, the alignment of the memory address). A value of 0 or an omitted align argument means that the operation has the preferential alignment for the target. It is the responsibility of the code emitter to en...

Anton Korobeynikov wrote: >> In the insrtuction >> %1 = load i32** %y_addr, align 4 >> what is the meaning of align 4?? >> Can anyone explain? >> > >From http://llvm.org/docs/LangRef.html#i_load : > > "The optional constant align argument specifies the alignment of the > operation (that is, the alignment of the memory address). A value of 0 > or an omitted align argument means that the operation has the > preferential alignment for the target. It is the responsibility o...

...39;t think it is)? Here, %q is based on %p, and %p is associated with the address range from alloca i32. But the range of the result from alloca is definitely smaller than 42. Since the LLVM IR does not state that load/store-ing out-of-bound address is undefined http://llvm.org/docs/LangRef.html#i_load http://llvm.org/docs/LangRef.html#i_store I looked into the alias-rule to find answers. Now, come back to the inttoptr and ptrtoint questions. When we consider a memory access via pointers from int is defined, do we mean 1) the value of the pointer happens to equal to an address within a rang...

...%q > is based on %p, and %p is associated with the address range from > alloca i32. But the range of the result from alloca is definitely > smaller than 42. Since the LLVM IR does not state that load/store-ing > out-of-bound address is undefined >   http://llvm.org/docs/LangRef.html#i_load >   http://llvm.org/docs/LangRef.html#i_store > I looked into the alias-rule to find answers. That doesn't really have anything to do with aliasing, but it's definitely undefined. Don't know off the top of my head where that is stated in LangRef. > Now, come back to the intt...

...++ front-ends have been updated to support volatile variables. In the LLVM representation, loads and stores can now be marked as being volatile (in contrast to C, "declarations" are not marked as volatile). This is described here: http://llvm.cs.uiuc.edu/docs/LangRef.html#i_load http://llvm.cs.uiuc.edu/docs/LangRef.html#i_store The existing LLVM optimizations have been updated to honor volatile loads and stores. 7. Misha compiled a ton of random programs with LLVM and ran them with the X86 JIT (finding several bugs). This includes GNU coreutils, bison,...

...d on %p, and %p is associated with the address range from >> alloca i32. But the range of the result from alloca is definitely >> smaller than 42. Since the LLVM IR does not state that load/store-ing >> out-of-bound address is undefined >>   http://llvm.org/docs/LangRef.html#i_load >>   http://llvm.org/docs/LangRef.html#i_store >> I looked into the alias-rule to find answers. > > That doesn't really have anything to do with aliasing, but it's > definitely undefined.  Don't know off the top of my head where that is > stated in LangRef. >...

Hi folks, Assuming that I'm writing a pass and that for bizarre reasons I need to programmatically do the equivalent of a C/C++ sizeof on a Value (or a Type, it doesn't matter which really), yielding a result in bytes, what is the known-safe way to do this? I notice that doing something like struct thingy { ... some stuff ... }; ... printf("Size = %d",

On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion