[llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes

[Chris Bieneman via llvm-dev]

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.

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.

-Chris

> On Jan 9, 2019, at 7:47 AM, Mehdi AMINI <joker.eph at gmail.com> wrote:
> 
> 
> 
> On Wed, Jan 9, 2019 at 4:52 AM Alex Bradbury <asb at lowrisc.org <mailto:asb at lowrisc.org>> wrote:
> On Mon, 7 Jan 2019 at 19:35, Chris Bieneman <chris.bieneman at me.com <mailto:chris.bieneman at me.com>> wrote:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> 
> Although it's super handy to have it available, IMHO the risks of
> writing, submitting, and ultimately committing incorrect .td
> modifications mean that making LLVM_OPTIMIZED_TABLEGEN the default
> would be unwise.
> 
> But modifying a .td is not necessarily part of the main routine of developing on LLVM.
> 
> 
> It might be more feasible if there were a 'check-td'
> target that put all the .td specified in the CMakeLists for each
> configured target through a debug+asserts or release+asserts tblgen.
> 
> In fact maybe there should be a warning in the current CMake docs to
> indicate of using a no-asserts tblgen binary while hacking on LLVM.
> 
> How do you detect what is « hacking on LLVM » when running Cmake? Why do you single out tblgen assertions?
> 
> I was using an « external » llvm-tblgen most of the time I was hacking on LLVM to avoid constantly rebuilding it.
> 
> 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.
> 
> — 
> Mehdi
> 
> 
> 
> 
> Best,
> 
> Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190109/fffbd1ab/attachment.html>