[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