llvm dev - Sep 2019 - Setting llvm::TargetOptions::GuaranteedTailCallOpt in LTO Code Generation

Hi,

I am lead developer of a project that is using LLVM to implement an
ahead-of-time compiled functional language. We use llc -tailcallopt to
ensure that functions that end in a tail call are compiled to a tail call
at the machine level, because we have a number of cases in our interpreter
where functions with different function signatures call one another in
deeply nested recursive calls. We can't use `musttail` because the callee
and caller often have different signatures.

We would like to support link time optimization in our programming
language, because performance is important to us. However, there is no
clang flag to enable the GuaranteedTailCallOpt flag, and the only way to
pass target options to the lto plugin currently is via an unsupported API
that parses those flags to static variables. This works on Linux, but the
Mac OS linker does not actually initialize the TargetOptions that it passes
as an llvm::lto::Config based on the parsed static variables, and Apple is
uninterested in spending time supporting an unsupported LLVM API like
-mllvm (understandably).

Is there a change to the LLVM project that you might be willing to accept
that we might be able to create a patch for that would allow us to get link
time optimization enabled in our programming language on Mac OS, at least
in the future? And if so, is it possible that someone could give me
pointers on how to proceed? I'm a relative novice studying this code and
I'm not really sure how all the components fit together at a high level and
thus what the correct design for something like this would be.

Or am I going to have to resign myself to waiting until lld is well
supported at linking mach-o files?

Thanks,

-- 

Dwight Guth

Director of Engineering

Email: dwight.guth at runtimeverification.com

<https://www.runtimeverification.com>

<https://github.com/dwightguth>
<https://www.linkedin.com/company/3142238/>
  <https://twitter.com/rv_inc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190916/aef383d9/attachment-0001.html>

Hi,

I am lead developer of a project that is using LLVM to implement an
ahead-of-time compiled functional language. We use llc -tailcallopt to
ensure that functions that end in a tail call are compiled to a tail call
at the machine level, because we have a number of cases in our interpreter
where functions with different function signatures call one another in
deeply nested recursive calls. We can't use `musttail` because the callee
and caller often have different signatures.

We would like to support link time optimization in our programming
language, because performance is important to us. However, there is no
clang flag to enable the GuaranteedTailCallOpt flag, and the only way to
pass target options to the lto plugin currently is via an unsupported API
that parses those flags to static variables. This works on Linux, but the
Mac OS linker does not actually initialize the TargetOptions that it passes
as an llvm::lto::Config based on the parsed static variables, and Apple is
uninterested in spending time supporting an unsupported LLVM API like
-mllvm (understandably).

Is there a change to the LLVM project that you might be willing to accept
that we might be able to create a patch for that would allow us to get link
time optimization enabled in our programming language on Mac OS, at least
in the future? And if so, is it possible that someone could give me
pointers on how to proceed? I'm a relative novice studying this code and
I'm not really sure how all the components fit together at a high level and
thus what the correct design for something like this would be.

Or am I going to have to resign myself to waiting until lld is well
supported at linking mach-o files?

Thanks,

-- 

Dwight Guth

Director of Engineering

Email: dwight.guth at runtimeverification.com

<https://www.runtimeverification.com>

<https://github.com/dwightguth>
<https://www.linkedin.com/company/3142238/>
  <https://twitter.com/rv_inc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190918/f872d609/attachment-0001.html>

Hi Dwight,

Welcome to LLVM-dev! A few comments below. Cc'ing a few people who
hopefully can add info on some of the specific issues here.

Teresa

On Wed, Sep 18, 2019 at 9:04 AM Dwight Guth via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I am lead developer of a project that is using LLVM to implement an
> ahead-of-time compiled functional language. We use llc -tailcallopt to
> ensure that functions that end in a tail call are compiled to a tail call
> at the machine level, because we have a number of cases in our interpreter
> where functions with different function signatures call one another in
> deeply nested recursive calls.
>
Maybe a naive question - would that be fixable?

> We can't use `musttail` because the callee and caller often have
different
> signatures.
>
> We would like to support link time optimization in our programming
> language, because performance is important to us. However, there is no
> clang flag to enable the GuaranteedTailCallOpt flag, and the only way to
> pass target options to the lto plugin currently is via an unsupported API
> that parses those flags to static variables.
>
I assume you mean passing internal options via -mllvm through the linker?

> This works on Linux, but the Mac OS linker does not actually initialize
> the TargetOptions that it passes as an llvm::lto::Config based on the
> parsed static variables, and Apple is uninterested in spending time
> supporting an unsupported LLVM API like -mllvm (understandably).
>
lto::Config is part of the new LTO API. For the most part ld64 uses the old
legacy LTO API, and therefore does not even use llvm::lto::Config (the one
exception is to share the code for computing a cache key). But it doesn't
use this when invoking the code generation passes. I'm surprised that ld64
would not have a way to pass through internal llvm options - presumably
that is necessary for debugging and tuning. +Steven Wu <stevenwu at
apple.com> to
give more info here (I work on Linux code and therefore have only directly
used gold and lld, which both use the new LTO API).

> Is there a change to the LLVM project that you might be willing to accept
> that we might be able to create a patch for that would allow us to get link
> time optimization enabled in our programming language on Mac OS, at least
> in the future? And if so, is it possible that someone could give me
> pointers on how to proceed? I'm a relative novice studying this code
and
> I'm not really sure how all the components fit together at a high level
and
> thus what the correct design for something like this would be.
>
I guess the question is what interface would work for you. Would passing an
internal option like what works on lld or what you are doing with llc be
acceptable?

If you need a more officially supported mechanism, IMO the best way is
probably to create a new function attribute (e.g. 'forcetailcall' or
something equivalent to what GuaranteedTailCallOpt implies). That would be
completely linker agnostic and also not rely on internal options.

> Or am I going to have to resign myself to waiting until lld is well
> supported at linking mach-o files?
>
+Rui Ueyama <ruiu at google.com> and
+Eric Christopher <echristo at gmail.com> to comment on lld Mach-O
support.

Teresa

>
> Thanks,
>
> --
>
> Dwight Guth
>
> Director of Engineering
>
> Email: dwight.guth at runtimeverification.com
>
> <https://www.runtimeverification.com>
>
> <https://github.com/dwightguth>
> <https://www.linkedin.com/company/3142238/>  
<https://twitter.com/rv_inc>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Teresa Johnson |  Software Engineer |  tejohnson at google.com |
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190918/8bec7c04/attachment.html>