[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"

Mon Apr 10 16:41:04 PDT 2017

> On Apr 10, 2017, at 4:06 PM, JinGu <jingu at codeplay.com> wrote:
> 
> Hi Matthias,
> 
> >Jingu: Why do you even want a configuration that has LLVM_ENABLE_DUMP but does not have asserts enabled at the same time?
> 
> My colleague and I am doing custom project using clang/llvm. We have always wanted to use the IR Value's dump() to check our implementation correctly with Debug, Release and another builds. We thought the LLVM_ENABLE_DUMP is for it.
> 
dump() is meant as a helper for people using a debugger and we tend not to use it in code.

There are usually alternatives that you could use in code like `Value->print(errs());`...

- Matthias
> If Chris fixes http://bugs.llvm.org/show_bug.cgi?id=32283 <http://bugs.llvm.org/show_bug.cgi?id=32283>, I will be happy with it. :)
> Thanks,
> 
> JinGu Kang
> 
> On 10/04/2017 20:54, Matthias Braun wrote:
>> Jingu: Why do you even want a configuration that has LLVM_ENABLE_DUMP but does not have asserts enabled at the same time?
>> If this is just about getting a compiler fast enough to handle big code, most people seem to settle on CMAKE_BUILD_TYPE=Release, LLVM_ENABLE_ASSERTIONS=1 (aka. "RelWithAsserts"). 
>> 
>>> On Apr 10, 2017, at 12:42 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>> 
>>> 
>>>> On Apr 10, 2017, at 12:37 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote:
>>>> 
>>>> The situation is not consistent. Yes there are several places where we have the #if in the headers however there are far more cases where it is not. Some points here:
>>>> 
>>>> - This whole LLVM_DUMP_FUNCTION/LLVM_ENABLE_DUMP is about enabling the linker to strip (or not strip) the dumping function in release (debug) builds.
>>>> - For this it doesn't matter whether you have a declaration in the header or not, so it seems we standardized on not having it there.
>>>> - Things are 100% consistent so we sometimes have #ifs anyway.
>>>> - In case of templates we not only have the declaration but also an implementation in the header and need the #if there
>>>> - A similar problem arises in cases where the dump function was declared virtual and ends up in the vtable
>>>> - If you ask me then we shouldn't have LLVM_ENABLE_DUMP and just rely on NDEBUG to keep things simple... (We're in this strange state anyway where LLVM_ENABLE_DEBUG isn't even exposed as a cmake option).
>>>> - Either way, putting LLVM_ENABLE_DUMP into config.h would make the status-quo more consistent.
>>> 
>>> Using the config.h instead of the NDEBUG makes it robust against client using NDEBUG differently from what LLVM was built with. This seems really better to me.
>> Maybe we should rather go and remove the whole LLVM_ENABLE_DUMP setting as we probably will not set up a bot to it while at the same time we probably can't keep this consistently in a working state...
>> 
>> - Matthias
>> 
>>> 
>>> — 
>>> Mehdi
>>> 
>>> 
>>> 
>>>> 
>>>> - Matthias
>>>> 
>>>>> On Apr 10, 2017, at 12:17 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
>>>>> 
>>>>> Presently several of our headers have definitions like:
>>>>> 
>>>>> #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
>>>>>   void dump() const;
>>>>> #endif
>>>>> 
>>>>> Would it make sense to modify the build system to define LLVM_ENABLE_DUMP in config.h on debug builds?
>>>>> 
>>>>> Then we could wrap dump methods just based on LLVM_ENABLE_DUMP instead of two variables.
>>>>> 
>>>>> -Chris
>>>>> 
>>>>>> On Apr 10, 2017, at 1:34 PM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Mehdi
>>>>>>> Amini via llvm-dev
>>>>>>> Sent: Sunday, April 09, 2017 2:26 PM
>>>>>>> To: Matthias Braun
>>>>>>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; jingu at codeplay.com <mailto:jingu at codeplay.com>
>>>>>>> Subject: Re: [llvm-dev] Question about LLVM Building Error with "-
>>>>>>> DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
>>>>>>> 
>>>>>>> 
>>>>>>>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm-
>>>>>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote:
>>>>>>>> 
>>>>>>>> I think the idea is to keep NDEBUG out of headers when possible. So I
>>>>>>> think this should better be something like:
>>>>>>>> 
>>>>>>>> -#ifndef NDEBUG
>>>>>>>>  void dumpUses(unsigned RegNo) const;
>>>>>>>> -#endif
>>>>>>>> 
>>>>>>>> to be inline with various other dumpers (like MachineInstr::dump(),
>>>>>>> Pass::dump(), …)
>>>>>>> 
>>>>>>> I’m fine with leaving methods there, but we need to be able to compile-out
>>>>>>> fields in structure.
>>>>>> 
>>>>>> Hmmm seems to me this has come up in the past, and somebody pointed out
>>>>>> that it prevents building a debug-mode front-end against a release-mode LLVM.
>>>>>> (Why is that a valid use-case?  If I have an out-of-tree front end, and
>>>>>> especially one with a different license, I might well prefer to download
>>>>>> only LLVM releases rather than keep up-to-date with a live tree that I
>>>>>> build myself.  IIRC we do not provide debug-mode downloads, therefore 
>>>>>> anything that affects struct size/layout will break this use-case.)
>>>>>> --paulr
>>>>>> 
>>>>>>> 
>>>>>>> We already have ABI_BREAKING_CHECKS for instance to this end, the naming
>>>>>>> isn’t completely in line with LLVM_ENABLE_DUMP but could be unified.
>>>>>>> 
>>>>>>> —
>>>>>>> Mehdi
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> If that works for you please submit a patch to phabricator as described
>>>>>>> in http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch <http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch>
>>>>>>>> 
>>>>>>>> - Matthias
>>>>>>>> 
>>>>>>>>> On Apr 6, 2017, at 7:38 AM, jingu at codeplay.com <mailto:jingu at codeplay.com> via llvm-dev <llvm-
>>>>>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> I have tried to build llvm tip as following:
>>>>>>>>> 
>>>>>>>>> cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -
>>>>>>> DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm
>>>>>>>>> 
>>>>>>>>> After running 'make', I have got error messages like below.
>>>>>>>>> 
>>>>>>>>> llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void
>>>>>>> llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function
>>>>>>> declared in class ‘llvm::MachineRegisterInfo’
>>>>>>>>> 
>>>>>>>>> llvm/lib/CodeGen/MachineScheduler.cpp:2331:57: error: no ‘void
>>>>>>> llvm::SchedBoundary::dumpScheduledState()’ member function declared in
>>>>>>> class ‘llvm::SchedBoundary’
>>>>>>>>> 
>>>>>>>>> ...
>>>>>>>>> 
>>>>>>>>> It seems the "defined(LLVM_ENABLE_DUMP)" is needed on several
>>>>>>> locations. How do you think about it? I have attached the diff file about
>>>>>>> the locations for reference.  If I missed something, please let me know.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> JinGu Kang
>>>>>>>>> 
>>>>>>>>> <dump.diff>_______________________________________________
>>>>>>>>> LLVM Developers mailing list
>>>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> LLVM Developers mailing list
>>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20170410/77924e1c/attachment.html>