[llvm-dev] [RFC] Propeller: A frame work for Post Link Optimizations

[Xinliang David Li via llvm-dev]

On Fri, Sep 27, 2019 at 12:37 AM Kristof Beyls via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> Op vr 27 sep. 2019 om 02:32 schreef Sriraman Tallam via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> >
>> > If you have the MIR at the time you're making all the propeller
>> optimization decisions, why is the linker rewriting raw x86 assembly, as
>> opposed to performing the relevant transforms on MIR?
>>
>> MIR is still one module at a time.  We cannot do inter-procedural
>> basic block layout here.  We can do much more advanced stuff at the
>> whole-program level in the linker.  The relaxation code is the down
>> side.
>>
>> For more details, We strongly considered this.  We could run something
>> like a thin link in thin lto figure out the global layout and hand out
>> the relevant  subsets of the global decision  to each module.  This
>> looked more complicated and the individual pieces from each module
>> should still be globally laid out again by the linker.  This
>> constraints us on what we can do for layout and also does not work
>> well with future optimizations like global alignment like David
>> pointed out.
>>
>
> Apologies for the naive question.
> Why is MIR restricted to being only module at a time?
> If the restriction of only being able to do per-module processing at the
> MIR level would go away, then all these optimizations could be done in a
> compile step, and no support would need to be added to a linker?
> If the restriction to do cross-module optimization at the MIR level could
> be removed, would it become a better tradeoff to do this in an LTO compiler
> step rather than a linker step?
>

LTO style optimization uses the monolithic model which Propeller moves away
from. The design principle is as much as possible preparation work will be
done at module level, while the global step is lean and mean.

For layout/splitting/alignment/packing, linker is the right platform to
use. It sees/creates many things compiler does not, such as
PLTs/stubs/trampolines. etc. Besides, using linker allows inter-procedural
reordering of blocks in native object files as long as those files are
compiled with the right annotations. For instance, we can do per
application optimal layout for memcpy/memset functions from libc.a
depending on the profile data for that app.

David



>
> Thanks,
>
> Kristof
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190927/b66ee645/attachment-0001.html>