<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 6:45 PM Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 7:35 PM Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 12, 2018 at 7:14 PM Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>> wrote:<br>
><br>
> Quoting Rob Clark (2018-12-12 15:52:47)<br>
> > On Wed, Dec 12, 2018 at 6:25 PM Dylan Baker <<a href="mailto:dylan@pnwbakers.com" target="_blank">dylan@pnwbakers.com</a>> wrote:<br>
> > ><br>
> > > In the autotools discussion I've come to realize that we also need to talk about<br>
> > > the -DDEBUG guard. It seems that there are two different uses, and thus two<br>
> > > different asks about it:<br>
> > ><br>
> > > - Nine (and RadeonSI?) use -DDEBUG to hide generic debugging<br>
> > > - NIR and Intel (at least) use -DDEBUG to hide really expensive checks that are<br>
> > >   useful, but necessarily tank performance.<br>
> > ><br>
> > > The first group would like -DDEBUG in debugoptimized builds, the second<br>
> > > obviously doesn't.<br>
> > ><br>
> > > Is the right solution to move the first group being !NDEBUG, or would it be<br>
> > > better to split DEBUG into two different defines such as DEBUG_MESSAGES and<br>
> > > EXPENSIVE_VALIDATION (paint the bikeshed whatever color you like), with the<br>
> > > first for both debug and debugoptimized and the second only in debug builds?<br>
> ><br>
> > I guess my use cases for !=release builds are:<br>
> ><br>
> > + I want all the expensive checking because I'm not in it to win the<br>
> >   deqp/piglit fps race<br>
> > + I want debug syms for profiling and/or valgrind, but otherwise<br>
> >   want something close to a release build but with debug syms<br>
> ><br>
> ><br>
> > That said, I can get behind replacing DEBUG with !NDEBUG or<br>
> > EXPENSIVE_DEBUG or whatever permutation of that color folks prefer<br>
> ><br>
> ><br>
> > BR,<br>
> > -R<br>
><br>
> I guess I should have covered that:<br>
><br>
> autotools had effectively two build types "debug" and "not debug", "debug" set<br>
> "-DDEBUG -g -O2", "not debug" set -DNDEBUG<br>
><br>
> Meson has 4 build types, and a separate toggle for NDEBUG:<br>
> debug: -O0 -DDEBUG (we add -DDEBUG)<br>
> debugoptimzed: -O2 -g<br>
> release: -O2<br>
> plain: (nothing)<br>
<br>
I generally view meson as an upgrade in this respect, I guess mostly<br>
because I have no use for '-DDEBUG -g -O2' (ie. the -O0 equiv is fine<br>
by me).. maybe making meson debug config use -O2 would bridge the gap?<br>
 If so I have no problem with dropping -O0 and making debug config<br>
also use -O2<br></blockquote><div><br></div><div>Sounds good.</div><div><br></div><div>Also I think we should make -Db_ndebug=true the default for release builds. !NDEBUG enables a lot more debugging code than just assertions.<br></div></div></div></blockquote><div><br></div><div>Agreed.  In any driver using NIR, the assertions enabled by !NDEBUG are very expensive.<br></div><div><br></div><div>--Jason<br></div></div></div>