[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
> 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/83e38a53/attachment.html>


More information about the llvm-dev mailing list