[PATCH] D24688: Introduce "hosted" module flag.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 9 18:31:46 PST 2017


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





More information about the llvm-commits mailing list