[llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 9 07:47:21 PST 2019
On Wed, Jan 9, 2019 at 4:52 AM Alex Bradbury <asb at lowrisc.org> wrote:
> On Mon, 7 Jan 2019 at 19:35, Chris Bieneman <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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev