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

>
> 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? :)

For COFF/wasm does changing the default in the lld driver make sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201202/37644f81/attachment.html>

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.