[PATCH] D10414: Attach function attribute "arm-restrict-it" instead of passing arm-restrict-it as a backend-option

Jim Grosbach via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 10 14:34:43 PDT 2015


grosbach added a comment.

In http://reviews.llvm.org/D10414#243302, @jmolloy wrote:

> In an ideal world, yes. However there's no guarantee that all ARM implementors will (a) be able to commit to LLVM or (b) use ToT. Perhaps they're building a project that uses clang, or a specific version of clang, and this tuning option makes things go faster on their architecture.
>
> I'm not arguing about the defaults, just about the breakage of -mno-restrict-it.


Hmmm. I'm not sure I follow? In either case, why does what we do in clang matter at all? Especially for case (a); if they're not using LLVM, clang is completely irrelevant to them, right?

For (b), are you thinking of internal use by implementors when they're trying to decide what the right defaults should be for their tuning of the backend? In which case, would not an -mllvm option suffice?

The clang -m[no-]restrict-it is for end-users of clang, and that really doesn't seem the right thing to me. This is not a tuning parameter. It's a "what does the architecture I'm targeting support?" parameter. We only have even the backend option available for our own testing or we could (and should) get rid of that, too.


http://reviews.llvm.org/D10414





More information about the cfe-commits mailing list