[Bug c++/111243] New: The -Og option inlines functions, making for a poor debugging experience.

[Bug c++/111243] New: The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

            Bug ID: 111243
           Summary: The -Og option inlines functions, making for a poor
                    debugging experience.
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amohr at amohr dot org
  Target Milestone: ---

The docs recommend using -Og for debug builds, but that option inlines
functions which makes single-stepping in debuggers difficult/impossible. 
Adding -fno-inline fixes it.

The docs for -Og say that it disables -finline-functions-called-once. Should
-Og also do -fno-inline?

Here's a small example showing the difference between plain '-Og' and '-Og
-fno-inline':

https://godbolt.org/z/evs73cPT1

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |13.2.1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2023-08-31
           Keywords|                            |documentation
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
One of the points of -Og is to make debugging of C++ programs easier and that
absolutely requires some inlining as otherwise you step into a lot of
abstraction stuff.  So no, -finline is enabled on purpose for -Og, but it
should only inline where doing that improves code size.

For your example we probably either have wrong estimates or the C++ frontends
indicates we should ignore limits when inlining.

/tmp/t.cpp:14:13: optimized:  Inlining Foo::Foo(int)/1 into int Test(int)/3.
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
                Accounting size:2.00, time:2.00 on predicate exec:(true)
                Accounting size:1.00, time:0.41 on predicate exec:(true)
                Accounting size:0.50, time:0.20 on predicate exec:(true)
                Accounting size:0.50, time:0.30 on predicate exec:(true)
/tmp/t.cpp:14:13: note: Inlining Foo::Foo(int)/1 to int Test(int)/3 with
frequency 1.00

We estimate a growth of one which is visible by setting --param
early-inlining-insn=0:

/tmp/t.cpp:14:13: note: Considering inline candidate Foo::Foo(int)/1.
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
/tmp/t.cpp:14:13: missed:   will not early inline: int
Test(int)/3->Foo::Foo(int)/1, growth 1 exceeds --param early-inlining-insns

with --param early-inlining-insns=1 we still inline.  I guess it makes sense
to adjust this param by default for -Og (and to zero).  The intent is
to inline things like get() and set(x) in

struct X { int get() { return val; } void set(int v) { val = v; } int val; };

or other simple forwarders.

Would you agree with inlining these?  -Og is also documented to shift the
balance a bit towards performance compared to -O0 which for C++ code
necessarily means at least some inlining.  Possibly we should also amend
the documentation highlighting this.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #2 from Alex Mohr <amohr at amohr dot org> ---
Thanks much for looking at this, Richard.

I definitely understand what you're driving at with regard to stepping into
lots of C++ abstraction stuff.  But I think it gets blurry trying to
distinguish what's interesting to a human or not based on code size.

I think I could probably be convinced about inlining trivial getters, setters,
and forwarders like in your struct X. But I think code size doesn't work as the
deciding factor here. Just to illustrate, here's a modified example with '-Og
--param early-inlining-insns=0'.  The entire thing gets inlined, even though
every small function contains a conditional, and one even calls another:

struct Foo {
    explicit Foo(int in) { m = in > 0 ? in : 0; }
    int CalcFoo() const { int r = CalcBar(); return r < 0 ? -r : r; }
    int CalcBar() const { return m > 20 ? 20 : m; }
    int m;
};

int Test(int in) {
    Foo f(in);
    return f.CalcFoo() + f.CalcBar();
}

----------------------

Test(int):
        test    edi, edi
        mov     eax, 0
        cmovs   edi, eax
        mov     eax, 20
        cmp     edi, eax
        cmovg   edi, eax
        lea     eax, [rdi+rdi]
        ret

https://godbolt.org/z/hcsnzMrP9

On one hand it's awesome that the optimizer is so good... but this could be
pretty frustrating to debug.

Just FWIW when I compile with '-O0', I see a ~5x slowdown vs '-O2', but with
'-Og -fno-inline', I see just ~4x, so it's still a nice win over '-O0'.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The problem is that -Og aimed at solving two problems that are often in
conflict with each other - improving the debugging experience _and_ runtime
performance.
For the second goal it started as -O1 and then removing optimizations that make
the debugging experience bad which is transforms that re-order things because
then the debugging gets jumpy.  For the first goal we wanted to make
-fvar-tracking usable (not enabled at -O0) without big hits on compile-time
because that also allows the second goal as not all locals are materialized on
the stack.

So yes, we probably should tune down inlining for -Og, possibly also by
simply disabling the size/time estimation logic.  Inlining helps when
you single-step assembler instructions (because you have less instructions
to execute), it shouldn't make much difference when single-stepping
statements since the debugger should enter inlined bodies the same as
not inlined bodies?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
I remember I've asked "why not disable -finline with -Og" via gcc-help and
Jonathan told me it would make any "real" C++ programs stupidly slow.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A 4x slowdown isn't really acceptable IMHO. At that point, why not just use -O0
instead?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> it shouldn't make much difference when single-stepping
> statements since the debugger should enter inlined bodies the same as
> not inlined bodies?

'step' works OK, but 'next' and 'finish' are pretty useless. And if you can
only use 'step' then you end up descending into constructors and destructors of
temporaries and other uninteresting junk that isn't what you're trying to
debug.

For example, with this code:

#include <chrono>
#include <sstream>
#include <assert.h>

int main()
{
  using namespace std::chrono;
  const sys_seconds expected = sys_days(2023y/August/9) + 20h + 44min;
  file_time<seconds> tp;

  minutes offset;
  std::string abbrev;
  std::istringstream is("002023-08-09 21:44 +01 BST!");
  assert( is >> parse("%6F %R %z %Z", tp, abbrev, offset) );
}

Compiled with -Og I get:

$ gdb -q  -ex start -ex n -ex n -ex n -ex n -ex n -ex step -ex step -ex step
-ex step -ex step -ex step -ex step -ex  step -ex step  ./parse
Reading symbols from ./parse...
Temporary breakpoint 1 at 0x402296: file parse.cc, line 6.
Starting program: /tmp/parse 
[Thread debugging using libthread_db enabled]                                   
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at parse.cc:6
6       {
9         file_time<seconds> tp;
12        std::string abbrev;
88            __new_allocator() _GLIBCXX_USE_NOEXCEPT { }
13        std::istringstream is("002023-08-09 21:44 +01 BST!");
14        VERIFY( is >> parse("%6F %R %z %Z", tp, abbrev, offset) );
std::chrono::parse<char, std::char_traits<char>, std::allocator<char>,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>, std::chrono::time_point<std::filesystem::__file_clock,
std::chrono::duration<long, std::ratio<1l, 1l> > > >
(__offset=std::chrono::duration = { 73728min }, 
    __abbrev="", __tp=std::chrono::file_time = { 0s [2174-01-01 00:00:00] },
__fmt=0x406324 "%6F %R %z %Z")
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2980
2980                                                                     
&__offset);
std::chrono::__detail::_Parse<std::chrono::time_point<std::filesystem::__file_clock,
std::chrono::duration<long, std::ratio<1l, 1l> > >, char,
std::char_traits<char>, std::allocator<char> >::_Parse
(__offset=0x7fffffffd8d8, __abbrev=0x7fffffffd8b0, __tp=std::chrono::file_time
= { 0s [2174-01-01 00:00:00] }, 
    __fmt=0x406324 "%6F %R %z %Z", this=0x7fffffffd710) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2868
2868          _Parse(const _CharT* __fmt, _Parsable& __tp,
std::chrono::__detail::operator>> (__is=..., __p=...) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2887
2887          operator>>(__stream_type& __is, _Parse&& __p)
std::chrono::from_stream<char, std::char_traits<char>,
std::chrono::duration<long, std::ratio<1l, 1l> >, std::allocator<char> >
(__is=..., 
    __fmt=0x406324 "%6F %R %z %Z", __tp=std::chrono::file_time = { 0s
[2174-01-01 00:00:00] }, __abbrev=0x7fffffffd8b0, __offset=0x7fffffffd8d8)
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2806
2806        from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT*
__fmt,
std::chrono::from_stream<char, std::char_traits<char>,
std::chrono::duration<long, std::ratio<1l, 1l> >, std::allocator<char> >
(__is=..., 
    __fmt=0x406324 "%6F %R %z %Z", __tp=std::chrono::sys_time = { 0s
[1970-01-01 00:00:00] }, __abbrev=0x7fffffffd8b0, __offset=0x7fffffffd8d8)
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2705
2705        from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT*
__fmt,
2716          __detail::_Parser_t<_Duration> __p(__need);
std::chrono::__detail::_Parser<std::chrono::duration<long, std::ratio<1l, 1l> >
>::_Parser (__need=23, this=0x7fffffffd680)
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2136
2136          _Parser(__format::_ChronoParts __need) : _M_need(__need) { }
std::chrono::time_point<std::chrono::_V2::system_clock,
std::chrono::duration<long, std::ratio<86400l, 1l> > >::time_point
(this=0x7fffffffd688)
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono.h:935
935             constexpr time_point() : __d(duration::zero())
0x000000000040306b in
std::chrono::__detail::_Parser<std::chrono::duration<long, std::ratio<1l, 1l> >
>::operator()<char, std::char_traits<char>, std::allocator<char> >
(this=this@entry=0x7fffffffd680, __is=..., __fmt=0x406324 "%6F %R %z %Z",
__abbrev=0x7fffffffd8b0, __offset=__offset@entry=0x7fffffffd8d8)
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:3007
3007          ios_base::iostate __err = ios_base::goodbit;

I don't know what the __new_allocator constructor is doing there. The
time_point constructor isn't interesting.

If you replace any of those 'step' commands with 'next' you end up somewhere
you don't want to be:

$ gdb -q  -ex start -ex n -ex n -ex n -ex n -ex n -ex step -ex step -ex step
-ex n -ex step -ex step -ex step -ex  step -ex step  ./parse
Reading symbols from ./parse...
Temporary breakpoint 1 at 0x402296: file parse.cc, line 6.
Starting program: /tmp/parse 
[Thread debugging using libthread_db enabled]                                   
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at parse.cc:6
6       {
9         file_time<seconds> tp;
12        std::string abbrev;
88            __new_allocator() _GLIBCXX_USE_NOEXCEPT { }
13        std::istringstream is("002023-08-09 21:44 +01 BST!");
14        VERIFY( is >> parse("%6F %R %z %Z", tp, abbrev, offset) );
std::chrono::parse<char, std::char_traits<char>, std::allocator<char>,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
>, std::chrono::time_point<std::filesystem::__file_clock,
std::chrono::duration<long, std::ratio<1l, 1l> > > >
(__offset=std::chrono::duration = { 73728min }, 
    __abbrev="", __tp=std::chrono::file_time = { 0s [2174-01-01 00:00:00] },
__fmt=0x406324 "%6F %R %z %Z")
    at /home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2980
2980                                                                     
&__offset);
std::chrono::__detail::_Parse<std::chrono::time_point<std::filesystem::__file_clock,
std::chrono::duration<long, std::ratio<1l, 1l> > >, char,
std::char_traits<char>, std::allocator<char> >::_Parse
(__offset=0x7fffffffd8d8, __abbrev=0x7fffffffd8b0, __tp=std::chrono::file_time
= { 0s [2174-01-01 00:00:00] }, 
    __fmt=0x406324 "%6F %R %z %Z", this=0x7fffffffd710) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2868
2868          _Parse(const _CharT* __fmt, _Parsable& __tp,
std::chrono::__detail::operator>> (__is=..., __p=...) at
/home/jwakely/gcc/14/include/c++/14.0.0/bits/chrono_io.h:2887
2887          operator>>(__stream_type& __is, _Parse&& __p)
main () at /home/jwakely/gcc/14/include/c++/14.0.0/bits/ios_base.h:170
170       { return _Ios_Iostate(static_cast<int>(__a) & static_cast<int>(__b));
}
std::__cxx11::basic_istringstream<char, std::char_traits<char>,
std::allocator<char> >::~basic_istringstream (this=0x7fffffffd730, 
    __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:626
626           ~basic_istringstream()
627           { }
std::__cxx11::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::~basic_stringbuf (this=0x7fffffffd740,
__in_chrg=<optimized out>)
    at
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:79
79          class basic_stringbuf : public basic_streambuf<_CharT, _Traits>
627           { }
0x00007ffff7d4dd95 in std::__cxx11::basic_stringbuf<char,
std::char_traits<char>, std::allocator<char> >::~basic_stringbuf
(this=0x7fffffffd740, 
    __in_chrg=<optimized out>) at
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/sstream:79
79          class basic_stringbuf : public basic_streambuf<_CharT, _Traits>

Suddenly we skip past all the inlined stuff to the end of main() and the
destructors. I don't know how it got there, and I wrote most of that code.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think maybe this is a debuginfo and/or gdb problem, where 'next' doesn't
really do what you want, and 'finish' leaves the frame which has unpredictable
results if anything has been inlined (gdb shows you're in function 'foo' but
since that was actually inlined into its caller, running 'finish' returns from
foo's caller not from foo).

Ideally we'd keep the inlining, but improve the debug experience. Disabling
inlining seems like a hack to work around the fact that gdb doesn't really do
what we want.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #8 from Alex Mohr <amohr at amohr dot org> ---
(In reply to Jonathan Wakely from comment #5)
> A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> -O0 instead?

I've been using -O0 for years.  I was trying to move to -Og because of this
from the manual; particularly the second sentence:

"-Og should be the optimization level of choice for the standard
edit-compile-debug cycle, offering a reasonable level of optimization while
maintaining fast compilation and a good debugging experience. It is a better
choice than -O0 for producing debuggable code because some compiler passes that
collect debug information are disabled at -O0."

I definitely do not want to lose debug info.  The speed improvement is a nice
bonus, but top-notch debugging is my main goal for my debug builds.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alex Mohr from comment #8)
> (In reply to Jonathan Wakely from comment #5)
> > A 4x slowdown isn't really acceptable IMHO. At that point, why not just use
> > -O0 instead?
> 
> I've been using -O0 for years.  I was trying to move to -Og because of this
> from the manual; particularly the second sentence:
> 
> "-Og should be the optimization level of choice for the standard
> edit-compile-debug cycle, offering a reasonable level of optimization while
> maintaining fast compilation and a good debugging experience. It is a better
> choice than -O0 for producing debuggable code because some compiler passes
> that collect debug information are disabled at -O0."
> 
> I definitely do not want to lose debug info.  The speed improvement is a
> nice bonus, but top-notch debugging is my main goal for my debug builds.

I believe the only real issue is imprecise documentation: "It is a better
choice than -O0" has some caveats and it's not always true.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #10 from Alex Mohr <amohr at amohr dot org> ---
(In reply to Xi Ruoyao from comment #9)
> I believe the only real issue is imprecise documentation: "It is a better
> choice than -O0" has some caveats and it's not always true.

Is there a way to explicitly enable the compiler passes that collect debug info
that are disabled at -O0?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #11 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alex Mohr from comment #10)
> (In reply to Xi Ruoyao from comment #9)
> > I believe the only real issue is imprecise documentation: "It is a better
> > choice than -O0" has some caveats and it's not always true.
> 
> Is there a way to explicitly enable the compiler passes that collect debug
> info that are disabled at -O0?

I don't think so, many -fxxx optimize options have no effect at -O0.

But if you are using -Og you can add -fno-inline if you really don't want
inlining.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 1 Sep 2023, amohr at amohr dot org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243
> 
> --- Comment #10 from Alex Mohr <amohr at amohr dot org> ---
> (In reply to Xi Ruoyao from comment #9)
> > I believe the only real issue is imprecise documentation: "It is a better
> > choice than -O0" has some caveats and it's not always true.
> 
> Is there a way to explicitly enable the compiler passes that collect debug info
> that are disabled at -O0?

The main missing pass can be enabled with -fvar-tracking, at -O0 we
miss debug info for the prologue/epilogue of functions.  IIRC the
pass is disabled at -O0 because at -O0 we have many more memory
references and var-tracking becomes slow and memory hungry (YMMV).
With -Og automatic variables are no longer necessarily memory
backed so the situation is avoided to some extent.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the main problem of -Og for debug info is that we don't artificially
use all automatic vars at the end of their scopes, so if they aren't used
everywhere in the scope, they might not be available for debugging (or use
DW_OP_entry_value and the like that will only sometimes work but aren't
guaranteed to work all the time).

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #14 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #13)
> I think the main problem of -Og for debug info is that we don't artificially
> use all automatic vars at the end of their scopes, so if they aren't used
> everywhere in the scope, they might not be available for debugging (or use
> DW_OP_entry_value and the like that will only sometimes work but aren't
> guaranteed to work all the time).

That's bug 78685, isn't it?

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111243

--- Comment #15 from Alex Mohr <amohr at amohr dot org> ---
Thank you Richard B, Richard G, Xi, Jonathan, Jakub, and Eric for all the great
info.  Much appreciated.

With more experience using '-Og -fno-inline' I've found that sometimes
inspecting local variables doesn't work -- "<optimized out>".  So I'll continue
using -O0 for now.

To offer my perspective as a user, I think the manual should step back a bit
from recommending -Og as the default opt level for the edit/debug cycle, at
least in its current state.  Or at the very least, some mention of caveats
would be valuable.

That said I love that you're pursuing this direction and I'm eager to see how
this develops going forward.  Cheers!