llvm dev - Sep 2016 - RFC: module flag for hosted mode

In PR30403 we've been discussing how to encode -ffreestanding when using
LTO. This bit is currently dropped during LTO because its only
representation is in the TargetLibraryInfo created by clang (
http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258).

The proposal is to introduce a module flag that we set in any translation
unit compiled in hosted (i.e. -fno-freestanding) mode. At LTO time, if the
combined module has this flag (i.e. if any of the inputs have this flag),
we compile in hosted mode. This means that if we combine freestanding and
hosted modules, the entire resulting module will be compiled in hosted mode.

The justification for this behaviour (per Duncan) is that
hosted/freestanding is a property of the linkage environment, and if the
standard library is claimed to be available for any one translation unit in
the linkage unit, it should be available for every other translation unit
in the linkage unit.

One question that arises is how to handle old modules which were compiled
in hosted mode and lack the hosted module flag. With the above scheme, LTO
would run in freestanding mode if there are no contemporaneous modules. I
think this is probably fine, since (1) I'd normally expect there to be at
least one contemporaneous module (i.e. the main program, as opposed to old
modules belonging to a prebuilt library) and (2) the loop idiom recognizer
has already been run over these modules at compile time, so even if all
modules are old there's unlikely to be a huge perf regression.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160916/b690e7b1/attachment.html>

> On Sep 16, 2016, at 12:30 PM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
> 
> In PR30403 we've been discussing how to encode -ffreestanding when
using LTO. This bit is currently dropped during LTO because its only
representation is in the TargetLibraryInfo created by clang
(http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258
<http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258>).
> 
> The proposal is to introduce a module flag that we set in any translation
unit compiled in hosted (i.e. -fno-freestanding) mode. At LTO time, if the
combined module has this flag (i.e. if any of the inputs have this flag), we
compile in hosted mode. This means that if we combine freestanding and hosted
modules, the entire resulting module will be compiled in hosted mode.
> 
> The justification for this behaviour (per Duncan) is that
hosted/freestanding is a property of the linkage environment, and if the
standard library is claimed to be available for any one translation unit in the
linkage unit, it should be available for every other translation unit in the
linkage unit.
> 
> One question that arises is how to handle old modules which were compiled
in hosted mode and lack the hosted module flag. With the above scheme, LTO would
run in freestanding mode if there are no contemporaneous modules. I think this
is probably fine, since (1) I'd normally expect there to be at least one
contemporaneous module (i.e. the main program, as opposed to old modules
belonging to a prebuilt library) and (2) the loop idiom recognizer has already
been run over these modules at compile time, so even if all modules are old
there's unlikely to be a huge perf regression.
As an alternative view: since we didn’t support -ffreestanding in LTO mode
before, we should be able to just auto-upgrade these bitcode to the
-fnofreestanding version.

That said, as you mentioned it is probably not the common case and I don’t
expect us to hit this in practice.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160916/e75f7133/attachment.html>

+Eric and Akira (for thoughts on module flags)
> On 2016-Sep-16, at 12:47, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
>> On Sep 16, 2016, at 12:30 PM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
>> 
>> In PR30403 we've been discussing how to encode -ffreestanding when
using LTO. This bit is currently dropped during LTO because its only
representation is in the TargetLibraryInfo created by clang
(http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258).
>> 
>> The proposal is to introduce a module flag that we set in any
translation unit compiled in hosted (i.e. -fno-freestanding) mode. At LTO time,
if the combined module has this flag (i.e. if any of the inputs have this flag),
we compile in hosted mode. This means that if we combine freestanding and hosted
modules, the entire resulting module will be compiled in hosted mode.
>> 
>> The justification for this behaviour (per Duncan) is that
hosted/freestanding is a property of the linkage environment, and if the
standard library is claimed to be available for any one translation unit in the
linkage unit, it should be available for every other translation unit in the
linkage unit.
(Tangent, but related: I'm also wondering if this logic could/should be used
to encode other TLI flags, such as -fveclib=<lib>.  I.e., if one
translation unit has -fveclib=Accelerate, does that imply that we can use that
for the entire linkage unit?  If there's a conflict, such as -fveclib=SVML
in one and -fveclib=Accelerate in another, can we safely pick the first one
arbitrarily?)
>> One question that arises is how to handle old modules which were
compiled in hosted mode and lack the hosted module flag. With the above scheme,
LTO would run in freestanding mode if there are no contemporaneous modules. I
think this is probably fine, since (1) I'd normally expect there to be at
least one contemporaneous module (i.e. the main program, as opposed to old
modules belonging to a prebuilt library) and (2) the loop idiom recognizer has
already been run over these modules at compile time, so even if all modules are
old there's unlikely to be a huge perf regression.
> 
> As an alternative view: since we didn’t support -ffreestanding in LTO mode
before, we should be able to just auto-upgrade these bitcode to the
-fnofreestanding version.
> 
> That said, as you mentioned it is probably not the common case and I don’t
expect us to hit this in practice.
I completely agree with Mehdi here.  We could auto-upgrade to -fno-freestanding,
but it's also not important.