llvm dev - Apr 2017 - 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

> -----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

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>

> 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>