
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 16, 2016, at 12:30 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 (<a href="http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258" class="">http://llvm-cs.pcc.me.uk/tools/clang/lib/CodeGen/BackendUtil.cpp#258</a>).<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div></div>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.<div class=""><br class=""></div><div class="">That said, as you mentioned it is probably not the common case and I don’t expect us to hit this in practice.</div><div class=""><br class=""></div><div class="">— </div><div class="">Mehdi</div><div class=""><br class=""></div></body></html>