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

Mon Apr 10 16:06:24 PDT 2017

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.

If Chris fixes 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] 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
>>>>>>>
>>>>>>> - 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
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/62c556b9/attachment.html>