[llvm-dev] Rewriting calls to varargs functions

[Dávid Bolvanský via llvm-dev]

It could save useless parsing in s/f/printf during runtime.

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.



2018-05-22 18:36 GMT+02:00 Hal Finkel <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>:
>
>>
>> On 05/22/2018 04:32 AM, Dávid Bolvanský via llvm-dev wrote:
>>
>> Hello,
>>
>> A new patch:
>> 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 listllvm-dev at lists.llvm.orghttp://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/llvm-dev/attachments/20180522/5d399c15/attachment.html>