[cfe-dev] [llvm-dev] Rewriting calls to varargs functions

[Hal Finkel via cfe-dev]

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

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