Page MenuHomePhabricator

Introduce "hosted" module flag.
Needs ReviewPublic

Authored by mehdi_amini on Sep 16 2016, 3:20 PM.

Details

Summary

This module flag is used to mark modules which were compiled in hosted
mode. The TargetLibraryInfoImpl class now uses this module flag to initialize
library availability information.

Fixes PR30403.

Diff Detail

Event Timeline

pcc updated this revision to Diff 71707.Sep 16 2016, 3:20 PM
pcc retitled this revision from to Introduce "hosted" module flag..
pcc updated this object.
pcc added reviewers: mehdi_amini, dexonsmith.
pcc added subscribers: llvm-commits, cfe-commits.

What does "hosted mode" mean?

pcc added a comment.Sep 21 2016, 1:40 PM

The word "hosted" takes its meaning from the C/C++ standards. It refers to a build environment where the standard library is guaranteed to be available.

Note that we've been rethinking this approach on the mailing list, see http://lists.llvm.org/pipermail/llvm-dev/2016-September/105035.html

mehdi_amini commandeered this revision.Jan 6 2017, 10:04 PM
mehdi_amini edited reviewers, added: pcc; removed: mehdi_amini.
mehdi_amini edited edge metadata.

Rebase

pcc edited edge metadata.Jan 6 2017, 10:07 PM

Didn't we figure out in the end that this could be a function attribute instead?

In 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."

Since this requires everyone generating llvm IR to add this module attribute for optimal codegen, it should be documented in release notes and the LangRef, I think.

I mean: it's unfortunate that it's needed at all, but at the very least it should be possible for people to find out about it.

Since this requires everyone generating llvm IR to add this module attribute for optimal codegen,

Not sure yet how it'll end up, I'll revamp this.
See also: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052114.html

it should be documented in release notes and the LangRef, I think.

Thanks, I'll try not to forget.

hfinkel added a subscriber: hfinkel.Jan 8 2017, 4:37 AM

Since this requires everyone generating llvm IR to add this module attribute for optimal codegen, it should be documented in release notes and the LangRef, I think.

And, for something like this, here: http://llvm.org/docs/Frontend/PerformanceTips.html

I mean: it's unfortunate that it's needed at all, but at the very least it should be possible for people to find out about it.

pcc added a comment.Jan 9 2017, 6:31 PM
In 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.

Thanks, I'll investigate function attributes then!