Mehdi Amini via llvm-dev
2017-Apr-09 21:26 UTC
[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> 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. 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 via llvm-dev <llvm-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 >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Robinson, Paul via llvm-dev
2017-Apr-10 18:34 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
> -----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; 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> 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 via llvm-dev <llvm- > 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 > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > _______________________________________________ > > LLVM Developers mailing list > > 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 > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chris Bieneman via llvm-dev
2017-Apr-10 19:17 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
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> 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> 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 via llvm-dev <llvm- >> 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 >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> 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 >> 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/80790ecf/attachment.html>
Mehdi Amini via llvm-dev
2017-Apr-10 19:34 UTC
[llvm-dev] Question about LLVM Building Error with "-DLLVM_ENABLE_DUMP" and "RelWithDebInfo"
> On Apr 10, 2017, at 11:34 AM, Robinson, Paul <paul.robinson at sony.com> 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> 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.)That’s why we’re not using NDEBUG but the ABI_BREAKING_… macro which is set by the llvm-config.h. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/1c863424/attachment.html>