[LLVMdev] [RFC] NoBuiltin Attribute

[David Blaikie]

On Feb 20, 2013 8:32 AM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
wrote:
>
> On 2/20/2013 10:19 AM, David Blaikie wrote:
>>
>>
>> I'm still not understanding a few things in this thread, including one
>> here: if you annotate only the calls to print (say) then how do you
>> handle the indirect calls that the back end might yet optimize down to a
>> constant & then attempt to simplify? Would all indirect calls be
>> annotated with all the unsimplifiable function names?
>
>
> Something like that.  Indirect calls could be conservatively marked as
"no-builtin-everything", to limit the amount of data attached to them.
Metadata could be used to indicate exactly which target functions were of
interest, but it could be ignored without violating the original options.
>
>
>
>> I'm not quite sure what you mean by 'can be placed on calls from the
>> beginning'. One of the core issues here is LTO where two bit code files
>> were compiled with different options and then linked together - then one
>> function from one bitcode is inclined into a function from the other -
>> in this case there was no opportunity to have marked the latter with the
>> right attribute ahead of time.
>
>
> I don't think it should be marked with anything.  Maybe this is the root
cause of this ongoing misunderstanding.  If the user compiles one function
with no-builtin-printf, then only the calls to printf that were originally
in this function should be subjected to this restriction.  If this function
is then inlined into another function that didn't have any no-builtin
attributes, then calls to printf originating from that other functions are
not restricted.  This way you can end up with two calls to printf in the
same function, one of them restricted, the other one unrestricted.

Sure, if you're willing to sacrifice the possible simplification of all
indirect calls in any function that has even one nobuiltin requirement.

1) annotate calls
Pro: you can inline calls without pessimizing the function you inline into
Con: you pessimize all indirect calls in functions with at least one
nobuiltin requirement

2) annotate functions
Pro: you don't penalize indirect calls
Con: you either penalize functions that are inlined into, or you avoid
inlining.

Now, surem , I would guess the number of indirect calls that end up being
simplified is probably fairly small (though I don't really have a clue)
which would err in favor of (1), but I just wanted to be clear what we're
trading off.

Were there any other options being considered or benefits/drawbacks of
these options?

>
>
> -Krzysztof
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/40e0370c/attachment.html>