search for: i_stor

...on tests: http://smooshlab.apple.com:8010/builders/clang-i386-darwin9/builds/5022 > As for documentation, where should that go in LangRef.html? There's > nothing there yet that really talks about special metadata. I can make up > a section if that seems appropriate. Add it to the #i_store section, thanks. -Chris

...ldbot bug but it's certainly not what I would expect. > > As for documentation, where should that go in LangRef.html? There's > > nothing there yet that really talks about special metadata. I can make > > up a section if that seems appropriate. > > Add it to the #i_store section, thanks. Ok. This can also affect loads too so I'll add something for that too. -Dave

...ble which takes me back to my initial question at http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022590.html - isn't there a way to obtain the address of an argument? Because doing a store seems to copy the variable and expose the address of the copy - http://www.llvm.org/docs/LangRef.html#i_store is not very clear on what's going on. You can imagine that if you try to do something like taint analysis you want to track each access to a memory location - therefore something like the above would be needed. Any ideas? Thanks, Paul On Sun, May 24, 2009 at 10:47 PM, Nick Lewycky <nicho...

...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 range of an allocated object, or 2) the value...

On Monday 15 February 2010 15:08:22 Chris Lattner wrote: > On Feb 15, 2010, at 1:04 PM, David Greene wrote: > >> FWIW, this is because you broke the encoding of an instruction in your > >> patch. This is incorrect: > >> > >> +def MOVNTDQ_64mr : PSI<0xE7, MRMDestMem, (outs), (ins f128mem:$dst, > >> VR128:$src), +

...th 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 inttoptr and ptrtoint questions. When we > consid...

...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, ed, gawk, gnugo, xboard, nano, gnuchess, screen, grep,...

...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 inttoptr and ptrtoint...

On Feb 15, 2010, at 1:04 PM, David Greene wrote: >> FWIW, this is because you broke the encoding of an instruction in your >> patch. This is incorrect: >> >> +def MOVNTDQ_64mr : PSI<0xE7, MRMDestMem, (outs), (ins f128mem:$dst, >> VR128:$src), + "movntdq\t{$src, $dst|$dst, $src}", >> + [(alignednontemporalstore

Paul Martin wrote: > > Nick, > Thanks for the quick answer. > Dereferencing the pointer does yield the same result in both cases but > that's not what I want to do. I want to instrument the program > dynamically and keep track of certain memory locations which is a > problem if the same variable has different addresses for the > static/dynamic code - as far I see

Nick, Thanks for the quick answer. Dereferencing the pointer does yield the same result in both cases but that's not what I want to do. I want to instrument the program dynamically and keep track of certain memory locations which is a problem if the same variable has different addresses for the static/dynamic code - as far I see this is what it's happening but I have no clue why. Paul On

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