pcc added a comment. In https://reviews.llvm.org/D24688#638836, @mehdi_amini wrote:
> In https://reviews.llvm.org/D24688#638835, @pcc wrote: > > > Didn't we figure out in the end that this could be a function attribute > > instead? > > > We did? You wrote in PR30403: "I had a brief look at what it would take to > have a per-function TLI, and I'm not convinced that it would be worth the > effort." That was before I figured out (see http://lists.llvm.org/pipermail/llvm-dev/2016-September/105035.html) that it would not be sound to have mixed freestanding/hosted mean hosted. Specifically: > Here's one > scenario where we may break: suppose I LTO-link an implementation of memset > compiled with -ffreestanding with a program compiled with -fhosted. With > the proposed rule, the loop idiom recognizer may transform the body of the > memset function into a self-call. You later wrote that we should try not to default to freestanding: http://lists.llvm.org/pipermail/llvm-dev/2016-September/105083.html And I think I agree with that. To me that all makes it more reasonable to pursue a per-function approach. Later on (I don't think it happened on the mailing list or the bug, maybe on IRC) we had another look at GlobalOpt (referenced in PR30403 comment 6) and figured out that we can in fact find a function context. https://reviews.llvm.org/D24688 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
