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

Reply via email to