<div dir="ltr">Interesting ideas, thanks!<div><br></div><div>But only if "<span style="font-size:12.8px">printf("Hello, %s", "world") to printf("%s", "Hello, world")"-like transformation makes some sense, I think it is not worth it at all to do it.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Anyway, thank you for all your suggestions.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-23 2:11 GMT+02:00 Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Converting to puts is usually not possible: puts appends a newline to its output. The only really appropriate thing to convert to, that works in general, is fwrite. But we can't convert to that because we can't form the 'stdout' parameter (stdout might be a macro rather than a global, or might have a nontrivial mangling, so LLVM can't synthesize it). Also, converting printf("Hello, %s", "world") to printf("Hello, world") is likely a pessimization rather than an optimization for performance: printing a string via %s just needs to write the string, whereas printing a format string needs to scan for %s.<div><br></div><div>Having said all that, the opposite conversion (from printf("Hello, %s", "world") to printf("%s", "Hello, world")) may be marginally worthwhile. And there are some non-trivial tradeoffs here if you want to optimize for size. (Eg, some format string refactorings may permit more string constant reuse.)</div><div><div class="h5"><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 22 May 2018 at 10:26, Hubert Tong via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, May 22, 2018 at 12:59 PM, Dávid Bolvanský via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">It could save useless parsing in s/f/printf during runtime.</div></blockquote></span><div>A mix of calls to puts and calls to printf with format strings containing just a conversion specifier can help towards such a goal without mutating constants beyond the format string.<br> </div><div><div class="m_-1431877286527277845h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I think it could be quite useful. </div><div>After this transformation we would get fprintf(f, "ABC: %s", msg);  --> We could save one push/mov instruction + less parsing in printf every time we call it. We would just replace string constant "%s: %s" with "ABC: %s" and possibly orphaned "ABC" constant could be removed completely.</div><div><br></div><div><br></div></div><div class="m_-1431877286527277845m_6676098115723868606gmail-HOEnZb"><div class="m_-1431877286527277845m_6676098115723868606gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-05-22 18:36 GMT+02:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span>
    <p><br>
    </p>
    <div class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156moz-cite-prefix">On 05/22/2018 10:42 AM, Dávid Bolvanský
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Thanks.
        <div><br>
        </div>
        <div>Yes, to <span style="font-size:12.8px">substitute only some
            of the arguments. F</span><span style="font-size:12.8px">ormatting
            used by printf depends on the locale but only for double,
            float types I think - yes, I would not place </span><span style="font-size:12.8px">double/float </span><span style="font-size:12.8px">constants </span><span style="font-size:12.8px">i<wbr>nto the format string.</span></div>
      </div>
    </blockquote>
    <br></span>
    Okay. I think it's true that integers will be the same regardless of
    locale (so long as the ' flag is not used, as that brings in a
    dependence on LC_NUMERIC).<span><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div><span style="font-size:12.8px"><br>
              </span></div>
            <div><span style="font-size:12.8px">Why? To reduce number of
                constants (some of them could be merged into the format
                string) and number of args when
                calling printf/fprintf/sprintf<wbr>, etc..<br>
              </span></div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Sure, but it seems to me unlikely that this will affect performance.
    Is it a code-size optimization (this actually isn't obvious to me
    because the string representation might be longer than the binary
    form of the constant plus the extra instructions)?<span class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013HOEnZb"><font color="#888888"><br>
    <br>
     -Hal</font></span><div><div class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013h5"><br>
    <br>
    <blockquote type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2018-05-22 16:22 GMT+02:00 Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#FFFFFF"><span>
                <p><br>
                </p>
                <div class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771moz-cite-prefix">On
                  05/22/2018 04:32 AM, Dávid Bolvanský via llvm-dev
                  wrote:<br>
                </div>
                <blockquote type="cite">
                  <div dir="ltr">Hello,
                    <div><br>
                    </div>
                    <div>A new patch:</div>
                    <div><a href="https://reviews.llvm.org/D47159" target="_blank">https://reviews.llvm.org/D4715<wbr>9</a></div>
                    <div><br>
                    </div>
                    <div>proposes transformations like:</div>
                    printf("Hello, %s %d", "world", 123) - >
                    printf("Hello world 123")<br>
                  </div>
                </blockquote>
                <br>
              </span> To clarify, the real question here comes up when
              you can only substitute some of the arguments? If you can
              substitute all of the arguments, then you can turn this
              into a call to puts.<br>
              <br>
              In any case , why do you want to do this? Also, doesn't
              the formatting used by printf depend on the process's
              current locale?<br>
              <br>
               -Hal<br>
              <br>
              <blockquote type="cite"><span>
                  <div dir="ltr"><br>
                    As Eli noted:<br>
                    <br>
                    "I'm not sure we can rewrite calls to varargs
                    functions safely in general given the current state
                    of the C ABI rules in LLVM.<br>
                    <br>
                    Sometimes clang does weird things to conform with
                    the ABI rules, because the LLVM type system isn't
                    the same as the C system. For most functions, it's
                    pretty easy to tell it happened: if the IR signature
                    of the function doesn't match the expected
                    signature, something weird happened, so we can just
                    bail out. But varargs functions don't specify a
                    complete signature, so we can't tell if the clang
                    ABI code was forced to do something weird, like
                    split an argument into multiple values, or insert a
                    padding value. For example, for the target
                    mips64-unknown-linux-gnu, a call like
                    printf("asdf%Lf", 1.0L); gets lowered to the
                    following:<br>
                    <br>
                    %call = call i32 (i8*, ...) @printf(i8*
                    getelementptr inbounds ([5 x i8], [5 x i8]* @.str,
                    i32 0, i32 0), i64 undef, fp128
                    0xL00000000000000003FFF0000000<wbr>00000) #2"
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                    <div>I would to hear more suggestions whether it is
                      safe or not. Seems like for mips Clang produces
                      some weird IR, but e.g. x86 IR seems ok.</div>
                    <div><br>
                    </div>
                    <div>Any folks from Clang/LLVM to bring more
                      information about "varargs vs ABI vs LLVM vs
                      Clang"? </div>
                    <div>And whether we can rewrite calls
                      to varargs functions safely under some
                      conditions..</div>
                    <div><br>
                    </div>
                    <div>Thanks</div>
                    <div><br>
                    </div>
                    <div><br>
                    </div>
                  </div>
                  <br>
                  <fieldset class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771mimeAttachmentHeader"></fieldset>
                  <br>
                </span>
                <pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><span class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888">
</font></span></pre>
                <span class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888"> </font></span></blockquote>
              <span class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888"> <br>
                  <pre class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
                </font></span></div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="m_-1431877286527277845m_6676098115723868606gmail-m_6471266881870237013m_-322651739152344156moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </div></div></div>

</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div></div></div>
</blockquote></div><br></div>