<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 1/21/11 5:00 PM, Chuck Zhao wrote:
    <blockquote cite="mid:4D3A0FF7.4000405@eecg.toronto.edu" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      John,<br>
      <br>
      Thanks for the reply.<br>
      I agree with your comments that the "Memory" LLVM Spec refers to
      doesn't include stack.<br>
    </blockquote>
    <br>
    It includes stack objects (memory allocated by the alloca
    instruction) but not the stack frame (e.g., spill slots).<br>
    <br>
    <blockquote cite="mid:4D3A0FF7.4000405@eecg.toronto.edu" type="cite">
      <br>
      Let me leverage a bit further:<br>
      <br>
      If I need to work on high-level IRs (not machine dependent, not in
      the code-gen stage), is it reasonable to assume that<br>
      ALL LLVM IRs that have a result field will have potential to write
      stack?<br>
    </blockquote>
    <br>
    Strictly speaking, I would go so far as to assume that any LLVM IR
    instruction can write to the stack frame.<br>
    <br>
    <blockquote cite="mid:4D3A0FF7.4000405@eecg.toronto.edu" type="cite">
      <br>
      <br>
      E.g.<br>
      <span class="Apple-style-span" style="border-collapse: separate;
        color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style:
        normal; font-variant: normal; font-weight: normal;
        letter-spacing: normal; line-height: normal; orphans: 2;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: 2; word-spacing: 0px; font-size: medium;"><span
          class="Apple-style-span" style="text-align: left;">
          <pre>  <result> = add <ty> <op1>, <op2>          <i>; yields {ty}:result</i></pre>
        </span></span><br>
      <span class="Apple-style-span" style="border-collapse: separate;
        color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style:
        normal; font-variant: normal; font-weight: normal;
        letter-spacing: normal; line-height: normal; orphans: 2;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: 2; word-spacing: 0px; font-size: medium;"><span
          class="Apple-style-span" style="text-align: left;">
          <pre>  br i1 <cond>, label <iftrue>, label <iffalse>
  br label <dest>          <i>; Unconditional branch</i></pre>
        </span></span><br>
      ADD can (potential) write stack to store its result, while BR will
      NEVER write stack because its doesn't have a result.<br>
    </blockquote>
    <br>
    You might be able to get away with this on some platforms.  However,
    you can't assume this in general; the LLVM IR makes no guarantees at
    all about which instructions read and write the stack frame and
    which do not.  The branch could load its argument from the stack
    frame or from a global value pool.  On a VLIW machine, it could be
    packed into an instruction that also contains a read/write from/to
    the stack frame.  Maybe the processor only supports indirect branch
    instructions.<br>
    <br>
    Whether you want to count on LLVM IR branches writing to the stack
    depends on what hardware architecture you're using and what you're
    doing.  If you're counting memory accesses for a heuristic only on
    x86, then assuming branches don't write to memory seems like a
    reasonable assumption.  If you need an accurate count on all
    supported platforms, I'd look into analyzing the generated machine
    code.<br>
    <br>
    -- John T.<br>
      <br>
    <blockquote cite="mid:4D3A0FF7.4000405@eecg.toronto.edu" type="cite">
      <br>
      <br>
      Thank you<br>
      <br>
      Chuck<br>
      <br>
      <br>
      <br>
      <br>
      On 1/21/2011 5:33 PM, John Criswell wrote:
      <blockquote cite="mid:4D3A09D7.4090603@illinois.edu" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        On 1/21/11 2:50 PM, Chuck Zhao wrote:
        <blockquote cite="mid:4D39F197.6090306@eecg.toronto.edu"
          type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=ISO-8859-1">
          I need to figure out all LLVM Instructions that may write to
          memory.<br>
          <br>
          In <a moz-do-not-send="true"
            href="http://llvm.org/docs/tutorial/OCamlLangImpl7.html">http://llvm.org/docs/tutorial/OCamlLangImpl7.html</a>,
          it mentions that<br>
          "<span class="Apple-style-span" style="border-collapse:
            separate; color: rgb(0, 0, 0); font-family: 'Times New
            Roman'; font-style: normal; font-variant: normal;
            font-weight: normal; letter-spacing: normal; line-height:
            normal; orphans: 2; text-indent: 0px; text-transform: none;
            white-space: normal; widows: 2; word-spacing: 0px;
            font-size: medium;"><span class="Apple-style-span"
              style="text-align: left;">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.</span></span>"<br>
          <br>
          I take this as "StoreInst is the only one that writes to
          memory". <br>
        </blockquote>
        <br>
        There are intrinsic functions which write to memory also, such
        as memcpy.<br>
        <blockquote cite="mid:4D39F197.6090306@eecg.toronto.edu"
          type="cite"> <br>
          However, this doesn't seem to be enough.<br>
        </blockquote>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        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.<br>
        <br>
        -- John T.<br>
        <br>
        <br>
        <blockquote cite="mid:4D39F197.6090306@eecg.toronto.edu"
          type="cite"> <br>
          Consider: <br>
          ...<br>
          int a, b, d;<br>
          d = a + b;<br>
          ...<br>
          <br>
          The above code is turned into LLVM IR:<br>
          <pre wrap="">  %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 =  /<b class="moz-txt-star"><span class="moz-txt-tag">*</span>tail<span class="moz-txt-tag">*</span></b>/ 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
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><span class="Apple-style-span" style="font-family: Fixed,monospace; font-size: 14px;"></span></span>


</pre>
        </blockquote>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>