<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I can see both sides of this argument, but fundamentally I agree with Mehdi that we shouldn't treat table gen assertions differently from LLVM. We have no mechanism for enforcing that people build and test with assertions enabled before committing code, we also have no mechanism for enforcing verify-machine-instrs or a large number of other configurations that catch bugs. In the current development model we just expect that the bots will catch it all.<div class=""><br class=""></div><div class="">We could make the default tablegen build configuration Release+Asserts, and add an additional option to disable the asserts, but I'm not entirely convinced that is the right approach given how costly some of tablegen's asserts are.<br class=""><div class=""><br class=""></div><div class="">-Chris<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 9, 2019, at 7:47 AM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" class="">joker.eph@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class=""><br class="Apple-interchange-newline"><br class=""><div class="gmail_quote"></div></div></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="ltr" class="">On Wed, Jan 9, 2019 at 4:52 AM Alex Bradbury <<a href="mailto:asb@lowrisc.org" target="_blank" class="">asb@lowrisc.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">On Mon, 7 Jan 2019 at 19:35, Chris Bieneman <<a href="mailto:chris.bieneman@me.com" target="_blank" class="">chris.bieneman@me.com</a>> wrote:<br class="">><br class="">> Historically there was a request to make LLVM_OPTIMIZED_TABLEGEN On by default for debug builds, which I discouraged. At the time it was suggested that workflow was fairly new and untested in a lot of build configurations. Today I believe that situation is slightly better.<br class="">><br class="">> I believe there are still issues with it not working correctly in the Xcode generator, but I know people have used it successfully with Visual Studio.<br class="">><br class="">> I think that enabling it by default in Debug builds is probably reasonable for most generators, but anyone looking to make that change should expect some bumps in the road.<br class=""><br class="">Although it's super handy to have it available, IMHO the risks of<br class="">writing, submitting, and ultimately committing incorrect .td<br class="">modifications mean that making LLVM_OPTIMIZED_TABLEGEN the default<br class="">would be unwise.</blockquote><div dir="auto" class=""><br class=""></div></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div dir="auto" class="">But modifying a .td is not necessarily part of the main routine of developing on LLVM.</div></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">It might be more feasible if there were a 'check-td'<br class="">target that put all the .td specified in the CMakeLists for each<br class="">configured target through a debug+asserts or release+asserts tblgen.<br class=""><br class="">In fact maybe there should be a warning in the current CMake docs to<br class="">indicate of using a no-asserts tblgen binary while hacking on LLVM.</blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">How do you detect what is « hacking on LLVM » when running Cmake? Why do you single out tblgen assertions?</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I was using an « external » llvm-tblgen most of the time I was hacking on LLVM to avoid constantly rebuilding it.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">More importantly: assertions should catch internal issues with tblgen itself. Issues with invalid .td should not be implemented through assertions IMO but always-on checks.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">— </div><div dir="auto" class="">Mehdi</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class=""><br class="">Best,<br class=""><br class="">Alex</blockquote></div></div></div></div></blockquote></div><br class=""></div></div></body></html>