[PATCH] [Inliner] Use whitelist instead of blacklist when checking function attribute compatibility and make the check stricter

Akira Hatanaka ahatanak at gmail.com
Mon Mar 9 15:24:30 PDT 2015


On Tue, Mar 3, 2015 at 5:48 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

> I really don't like this. I really don't like the prior solution either.
>
> Today, we have subtle, hard to diagnose correctness bugs. Bad bad bad.
>
> With this we have subtle, hard to diagnose performance bugs combined with
> a bit of a maintenance nightmare to keep this up to date. Bad bad bad.
>
> I also fear the performance bugs will in practice happen much more often.
> I'm seriously worried about the string attributes for example.
>
> I think we need to back up and think of a better design for this. A *much*
> better design. Do you have any thoughts on how to do this in a more
> maintainable way? If not I'll try to write something else.
>
>
To make this more maintainable, I think there should be a way to add all
the information that is needed to decide whether a function is inlinable to
the definition of the function attribute. With this change, whoever wants
to define and add a new function attribute has to think hard about whether
the inliner should check for compatibility.

I'm looking into using table-gen to generate the target-independent enums
and functions that check the enum and string attributes to determine the
inlinability of a function, but I'm open to other ideas.

Naturally, if there are specific attributes that are casuing problems,
> let's get a targeted fix in place for those attributes.
>
>
> http://reviews.llvm.org/D7802
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150309/fb005790/attachment.html>


More information about the llvm-commits mailing list