[llvm-dev] [RFC] Expanding the scope of ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER

[Reid Kleckner via llvm-dev]

I can't speak for wasm, but on Windows people just invoke the linker
directly rather than doing this strange Unix dance of calling the compiler
to link. =P So, lld-link has to check the configure time setting.

On Wed, Dec 2, 2020 at 11:26 AM Fāng-ruì Sòng <maskray at google.com> wrote:

> On Wed, Dec 2, 2020 at 11:14 AM Arthur Eubanks <aeubanks at google.com>
> wrote:
> >>
> >> I added a comment on D92433. In lld/ELF, we generally don't recommend
> >> configure-time default values. We expect the compiler driver to handle
> platform differences
> >> We expect the driver to handle platform differences (e.g. default -pie)
> and pass
> >> the proper options to LLD. We can default to true and let the clang
> driver pass
> >> --no-lto-new-pass-manager to LLD if needed.
> >
> > That sounds fine to me as long as people don't use lld/ELF directly.
> Although it can't hurt to also change the default value,can it? :)
>
> Generally lld/ELF should not be invoked directly. I expect more so for
> LTO users.
> I should have said that my preference to a default
> --lto-new-pass-manager is weak: (a) the convention is not to have more
> configure-time options
> (b) having a configure-time variable for LLD does not seem to add lots
> of usefulness if the compiler driver will handle it. (This will add
> some complexity to tests and when it is time to move to new PM for
> everything and setting will need to be changed again)
>
> > For COFF/wasm does changing the default in the lld driver make sense?
>
> Adding Reid and Sam.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/ded2ae53/attachment.html>