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

[Eric Christopher]

FWIW this is on my list to look at in the next day or so.

On Thu, Mar 26, 2015, 9:40 PM Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Mar 24, 2015, at 11:16 AM, Akira Hatanaka <ahatanak at gmail.com> wrote:
>
> Any thoughts?
>
>
> This looks promising. It seems like it ought to address at least some of
> Chandler’s concerns with your previous patch. I’d like to see what the
> patch looks like for handling target-specific attributes.
>
> Chandler, are you OK with the general direction of this?
>
>
> On Fri, Mar 13, 2015 at 5:36 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
>
>> > On 2015-Mar-10, at 14:59, Akira Hatanaka <ahatanak at gmail.com> wrote:
>> >
>> > I came up with a patch that addresses the concerns Chandler brought up.
>> This is still a WIP patch, so I would like to hear feedback before I go too
>> far down this route.
>> >
>> > The updated patch takes a completely different approach to determining
>> a function's inlinability. It uses table-gen to specify the attributes'
>> enums along with their inlinability/compatibility information. With this
>> new approach, whenever someone defines and uses a new attribute in the IR,
>> the compatibility information has to be added too. Currently, there is only
>> one field in class Attr in the .td file, which indicates whether the
>> inliner should check the attribute's compatibility, but it should be easy
>> to add other fields or rules if other passes need more information about
>> the attribute. For example, I think most of the code in the verifier that
>> looks at attributes in the IR can be auto-generated by table-gen.
>> >
>> > The patch doesn't add any checks for the target-specific function
>> attribute strings, but it can be done in a similar way to
>> target-independent enum attributes. Functions are auto-generated by
>> table-gen from .td files and are passed to the constructor of
>> TargetIRAnalysis to enable checking compatibility of target-specific
>> attributes. Also, we should be able to generate code that checks the
>> validity of a string attribute added to the IR, which is something we
>> currently lack. It would issue a warning or error if a string not
>> recognized by the target was used to get an attribute from the attribute
>> set.
>> >
>>
>> This direction SGTM.  @Chandler, does this look better to you?
>>
>> >
>> > http://reviews.llvm.org/D7802
>> >
>> > Files:
>> >  include/llvm/Analysis/InlineCost.h
>> >  include/llvm/Analysis/TargetTransformInfo.h
>> >  include/llvm/IR/Attributes.h
>> >  include/llvm/IR/EnumAttributes.td
>> >  lib/Analysis/IPA/InlineCost.cpp
>> >  lib/Analysis/TargetTransformInfo.cpp
>> >  lib/CodeGen/LLVMTargetMachine.cpp
>> >  lib/IR/Attributes.cpp
>> >  lib/IR/Makefile
>> >  lib/Target/AArch64/AArch64TargetMachine.cpp
>> >  lib/Target/ARM/ARMTargetMachine.cpp
>> >  lib/Target/Mips/MipsTargetMachine.cpp
>> >  lib/Target/NVPTX/NVPTXTargetMachine.cpp
>> >  lib/Target/PowerPC/PPCTargetMachine.cpp
>> >  lib/Target/R600/AMDGPUTargetMachine.cpp
>> >  lib/Target/TargetMachine.cpp
>> >  lib/Target/X86/X86TargetMachine.cpp
>> >  lib/Target/XCore/XCoreTargetMachine.cpp
>> >  utils/TableGen/Attribute.cpp
>> >  utils/TableGen/TableGen.cpp
>> >  utils/TableGen/TableGenBackends.h
>> >
>> > EMAIL PREFERENCES
>> >  http://reviews.llvm.org/settings/panel/emailpreferences/
>> > <D7802.21626.patch>
>>
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150327/1b52864b/attachment.html>