<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><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><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="gmail-HOEnZb"><div class="gmail-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="gmail-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="gmail-m_6471266881870237013HOEnZb"><font color="#888888"><br>
<br>
-Hal</font></span><div><div class="gmail-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="gmail-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="gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771mimeAttachmentHeader"></fieldset>
<br>
</span>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="gmail-m_6471266881870237013m_-322651739152344156m_7035160539680259771moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="gmail-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="gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888">
</font></span></pre>
<span class="gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888"> </font></span></blockquote>
<span class="gmail-m_6471266881870237013m_-322651739152344156HOEnZb"><font color="#888888"> <br>
<pre class="gmail-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="gmail-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">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>