[LLVMdev] all LLVM Instructions that may write to memory -- other than StoreInst?

[Chuck Zhao]

John,

Thanks for the reply.
I agree with your comments that the "Memory" LLVM Spec refers to doesn't 
include stack.

Let me leverage a bit further:

If I need to work on high-level IRs (not machine dependent, not in the 
code-gen stage), is it reasonable to assume that
ALL LLVM IRs that have a result field will have potential to write stack?


E.g.

   <result>  = add<ty>  <op1>,<op2>           /; yields {ty}:result/


   br i1<cond>, label<iftrue>, label<iffalse>
   br label<dest>           /; Unconditional branch/


ADD can (potential) write stack to store its result, while BR will NEVER 
write stack because its doesn't have a result.


Thank you

Chuck




On 1/21/2011 5:33 PM, John Criswell wrote:
> On 1/21/11 2:50 PM, Chuck Zhao wrote:
>> I need to figure out all LLVM Instructions that may write to memory.
>>
>> In http://llvm.org/docs/tutorial/OCamlLangImpl7.html, it mentions that
>> "In LLVM, all memory accesses are explicit with load/store 
>> instructions, and it is carefully designed not to have (or need) an 
>> "address-of" operator."
>>
>> I take this as "StoreInst is the only one that writes to memory".
>
> There are intrinsic functions which write to memory also, such as memcpy.
>>
>> However, this doesn't seem to be enough.
>
> Your observation is correct.  Strictly speaking, any instruction can 
> write to memory after code generation because it may access a stack 
> spill slot or a function parameter which the ABI places on the stack.
>
> When the Language Reference Manual talks about writing to memory, it 
> is talking about writing to memory that is visible at the LLVM IR 
> level.  The stack frame is invisible at the LLVM IR level.  Put 
> another way, "memory" is a set of memory locations which can be 
> explicitly accessed by LLVM load and store instructions and are not in 
> SSA form; it is not all of the memory within the computer.
>
> If you're interested in finding instructions that write to RAM 
> (including writes to stack spill slots), it may be better to work on 
> Machine Instructions within the code generator framework.
>
> -- John T.
>
>
>>
>> Consider:
>> ...
>> int a, b, d;
>> d = a + b;
>> ...
>>
>> The above code is turned into LLVM IR:
>>    %0 = load i32* @a, align 4
>>    %1 = load i32* @b, align 4
>>    %2 = add nsw i32 %1, %0
>>    store i32 %2, i32* @d, align 4
>>
>> Is it possible that temps such as %0, %1 and/or %2 will NOT being register allocated later in the compilation stage, and thus left in memory?
>>
>> The above code, when converted back to C level, looks like this:
>> ...
>>    unsigned int llvm_cbe_tmp__6;
>>    unsigned int llvm_cbe_tmp__7;
>>    unsigned int llvm_cbe_tmp__8;
>>    unsigned int llvm_cbe_tmp__9;
>>
>>    llvm_cbe_tmp__6 = *(&a);
>>    llvm_cbe_tmp__7 = *(&b);
>>    llvm_cbe_tmp__8 = ((unsigned int )(((unsigned int )llvm_cbe_tmp__7) + ((unsigned int )llvm_cbe_tmp__6)));
>>    *(&d) = llvm_cbe_tmp__8;
>>    llvm_cbe_tmp__9 =  /*tail*/ printf(((&_OC_str.array[((signed int )0u)])), llvm_cbe_tmp__8);
>> ...
>>
>> It seems the compiler-generated temps are _actually_ left on stack, and writes to them are actually writes to stack memory (via load, add, ...).
>>
>>
>>
>> I am confused here.
>> Could somebody help to clarify it?
>>
>> Thank you
>>
>> Chuck
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110121/9276a7a2/attachment.html>