hi, Aaron
The reason why i not use of TargetSpecificAttr is as follows.If I plan to
support a new platform, I don't want to let users use certain attributes
because of hardware or simply not want to. Yes, we can use TargetSpecificAttr,
but if we use TargetSpecificAttr that we need to include platforms other than
unsupported platforms, but we just need to exclude that platform, using
TargetSpecificAttr may not be a good idea.
------------------ ???????? ------------------
??????: "Aaron Ballman"<aa...@aaronballman.com>;
????????: 2018??5??2??(??????) ????10:05
??????: "????"<772847...@qq.com>;
????: "cfe-commits"<cfe-commits@lists.llvm.org>;
????: Re: If I want to disable certain attributes, such as "swiftcall",isthere
any way to do it now?
On Wed, May 2, 2018 at 4:59 AM, ???? <772847...@qq.com> wrote:
> Thanks.
>
> If I remove some specific attributes, now I can think of the following
> method.First of all, let me talk about my method.
>
> 1.Define target platforms that do not support attributes.such as def
> TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
>
> 2.Define TargetNotSupportedAttr class.such as class
> TargetNotSupportedAttr<TargetArch target> ;
Why not make use of TargetSpecificAttr to mark the attributes that are
specific to a target rather than marking the attributes not supported
by a target?
> 3.Using this approach, we need to modify the
> cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the code in
> the GenerateHasAttrSpellingStringSwitch function looks like this:
>
> if(Attr->isSubClassOf("TargetNotSupportedAttr")) { // add
>
> #define GenerateTargetNotSupportedAttrChecks
> GenerateTargetSpecificAttrChecks // add
>
> const Record *R = Attr->getValueAsDef("Target"); // add
>
> std::vector<std::string> Arches =
> R->getValueAsListOfStrings("Arches"); // add
>
> GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
> // add
>
> TestStr = !Test.empty() ? Test + " ? " + " 0 :" +
> llvm::itostr(Version) : "0"; // add
>
> } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>
> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we don??t
> need to generate the attribute class, so add the following code in
> EmitClangAttrClass
>
> if (R->getName() != "TargetSpecificAttr" &&
>
> R->getName() != "TargetNotSupportedAttr?? && //add
>
> SuperName.empty())
>
> SuperName = R->getName();
>
>
> If I use this method, is it correct?
It seems like it would work, yes.
~Aaron
>
>
>
>
> ------------------ ???????? ------------------
> ??????: "Aaron Ballman"<aa...@aaronballman.com>;
> ????????: 2018??4??29??(??????) ????3:07
> ??????: "????"<772847...@qq.com>;
> ????: "cfe-commits"<cfe-commits@lists.llvm.org>;
> ????: Re: If I want to disable certain attributes, such as "swiftcall",
> isthere any way to do it now?
>
> On Fri, Apr 27, 2018 at 11:23 PM, ???? via cfe-commits
> <cfe-commits@lists.llvm.org> wrote:
>> As the title says,thanks.
>
> You could build a custom clang with specific attributes removed, but
> there are no compiler flags that allow you to disable arbitrary
> attributes like swiftcall.
>
> ~Aaron_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
