JinGu via llvm-dev
2017-Apr-10 23:06 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
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>
Matthias Braun via llvm-dev
2017-Apr-10 23:41 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
> 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>
jingu@codeplay.com via llvm-dev
2017-Apr-11 09:40 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
I appreciate for your kind comment Matthias. I will try it. :) Thanks again, JinGu Kang On 11/04/17 00:41, Matthias Braun wrote:> >> On Apr 10, 2017, at 4:06 PM, JinGu <jingu at codeplay.com >> <mailto: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, 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/d316c253/attachment-0001.html>