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

Akira Hatanaka ahatanak at gmail.com
Tue Apr 7 17:56:10 PDT 2015


Yes, I that works for me. I've been working on rewriting the .td file, but
I can do that later.

There are other attributes that we need to check besides target-cpu and
target-features:

- Fast FP math attributes: I think we should reject inlining if the caller
has a fast fp-math attribute (e.g., unsafe-fp-math = true) but the callee
doesn't. Alternatively, we can change the caller's fp-math attribute (to
unsafe-fp-math = false). I know the long term solution would be to model
these attributes at the instruction-level, but until we make that change,
we should treat them as function attributes.
- NoImplicitFloat.
- Probably we should check some of the target-specific attributes too.

On Tue, Apr 7, 2015 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote:

> Hi Akira,
>
> I think for right now since it's fairly trivial to come up with a testcase
> that will run into problems we should do a quick conservative patch to the
> inliner first that will enable some progress - i.e. we should check the
> target-cpu and target-features strings and if they don't match exactly go
> ahead and reject in the inliner. This is, obviously, much less than
> optimal, but will get us to an iterative solution.
>
> Thoughts?
>
> -eric
>
>
> 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/20150407/535ebad1/attachment.html>


More information about the llvm-commits mailing list