[llvm-dev] RFC: LTO should use -disable-llvm-verifier
Duncan P. N. Exon Smith via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 15 15:31:07 PDT 2015
> On 2015-Sep-02, at 19:31, Peter Collingbourne <peter at pcc.me.uk> wrote:
>
> On Thu, Sep 03, 2015 at 01:10:42AM +0000, Eric Christopher wrote:
>> On Tue, Sep 1, 2015 at 10:43 AM Duncan P. N. Exon Smith <
>> dexonsmith at apple.com> wrote:
>>
>>>
>>>> On 2015-Aug-31, at 18:09, Eric Christopher <echristo at gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Aug 31, 2015 at 5:50 PM Duncan P. N. Exon Smith <
>>> dexonsmith at apple.com> wrote:
>>>>
>>>>> On 2015-Aug-31, at 12:21, Eric Christopher <echristo at gmail.com> wrote:
>>>>> Yep. This is where I was going :)
>>>>
>>>> Glad I found consensus, but I want to double-check that this makes
>>>> sense to add to the driver. I didn't quite think through the
>>>> implications myself.
>>>>
>>>> Since the driver doesn't know if there's any bitcode, or if LTO is
>>>> going to be invoked, it seems like I'll have to change the noasserts
>>>> driver to *always* pass the option to the linker just in case we are
>>>> doing LTO. Is this reasonable?
>>>>
>>>> Also, I realized that passing `-mllvm -disable-llvm-verifier` to ld64
>>>> is redundant... so I'm thinking `-mllvm -disable-verify`. Make
>>>> sense?
>>>>
>>>> *sigh* Reasons to hate the driver interface again...
>>>>
>>>> I guess this is ok. Could possibly add it to the existing terrible
>>> "enable this pass" interface on liblto as well.
>>>
>>> The linker doesn't know whether clang was built with asserts, though.
>>>
>>> We could just make it implicit: move the decision to libLTO itself. Given
>>> that clang and libLTO.dylib are different executables anyway -- and you
>>> might be interposing an asserts libLTO.dylib to use with an installed clang
>>> -- maybe it's even better?
>>>
>>>
>> *nod* We could do that. Seems better than the alternative.
>
> +1
Finally got back to this. Done in r247729.
I didn't modify gold-plugin.cpp, as I don't have a good way to test it,
but someone else should be able to do it pretty easily.
More information about the llvm-dev
mailing list