[llvm-dev] Rewriting calls to varargs functions

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Tue May 22 11:20:14 PDT 2018


On 05/22/2018 11:59 AM, Dávid Bolvanský wrote:
> It could save useless parsing in s/f/printf during runtime.

Sure. But it is not clear that matters. printf is expensive anyway.
Maybe this matters more for snprintf? Have you benchmarked this?

>
> E.g. for heavy "fprint"ing code like fprintf(f, "%s: %s", TAG, msg); I
> think it could be quite useful. 
> 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.

Possibly. You also might end up substituting the string into many other
strings, resulting in many other longer strings, and thus increasing the
size of the executable.

 -Hal

>
>
>
> 2018-05-22 18:36 GMT+02:00 Hal Finkel <hfinkel at anl.gov
> <mailto:hfinkel at anl.gov>>:
>
>
>     On 05/22/2018 10:42 AM, Dávid Bolvanský wrote:
>>     Thanks.
>>
>>     Yes, to substitute only some of the arguments. Formatting used by
>>     printf depends on the locale but only for double, float types I
>>     think - yes, I would not place double/float constants into the
>>     format string.
>
>     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).
>
>>
>>     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, etc..
>
>     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)?
>
>      -Hal
>
>
>>
>>     2018-05-22 16:22 GMT+02:00 Hal Finkel <hfinkel at anl.gov
>>     <mailto:hfinkel at anl.gov>>:
>>
>>
>>         On 05/22/2018 04:32 AM, Dávid Bolvanský via llvm-dev wrote:
>>>         Hello,
>>>
>>>         A new patch:
>>>         https://reviews.llvm.org/D47159
>>>         <https://reviews.llvm.org/D47159>
>>>
>>>         proposes transformations like:
>>>         printf("Hello, %s %d", "world", 123) - > printf("Hello world
>>>         123")
>>
>>         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.
>>
>>         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?
>>
>>          -Hal
>>
>>>
>>>         As Eli noted:
>>>
>>>         "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.
>>>
>>>         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:
>>>
>>>         %call = call i32 (i8*, ...) @printf(i8* getelementptr
>>>         inbounds ([5 x i8], [5 x i8]* @.str, i32 0, i32 0), i64
>>>         undef, fp128 0xL00000000000000003FFF000000000000) #2"
>>>
>>>
>>>         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.
>>>
>>>         Any folks from Clang/LLVM to bring more information about
>>>         "varargs vs ABI vs LLVM vs Clang"? 
>>>         And whether we can rewrite calls to varargs functions safely
>>>         under some conditions..
>>>
>>>         Thanks
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         LLVM Developers mailing list
>>>         llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>         -- 
>>         Hal Finkel
>>         Lead, Compiler Technology and Programming Languages
>>         Leadership Computing Facility
>>         Argonne National Laboratory
>>
>>
>
>     -- 
>     Hal Finkel
>     Lead, Compiler Technology and Programming Languages
>     Leadership Computing Facility
>     Argonne National Laboratory
>
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180522/b86e8c91/attachment-0001.html>


More information about the llvm-dev mailing list