[Bug translator/26392] New: The optimizer would generate inefficient code which always evaluate dwarf ops eagerly

[Bug translator/26392] New: The optimizer would generate inefficient code which always evaluate dwarf ops eagerly

[agentzh at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26392

            Bug ID: 26392
           Summary: The optimizer would generate inefficient code which
                    always evaluate dwarf ops eagerly
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: agentzh at gmail dot com
  Target Milestone: ---

Created attachment 12773
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12773&action=edit
bad case using the default optimized translator and good case without
optimization

Consider the following example:

```
stap -e 'global a; probe process.begin { if (a == 1) next; println("===== aa")
println(ubacktrace()) }'
```

Regardless the value of the global variable `a`, the generated C code always
evaluates the value of `ubacktrace()` eagerly even before the `if (a == 1)`
check:

```C
    (void)
    ({
      ({
       
c->locals[c->nesting+1].function___global_ubacktrace__overload_0.__retvalue =
&l->__tmp0[0];
       
c->locals[c->nesting+1].function___global_ubacktrace__overload_0.__cur_frame =
          "\011<input>:1:79 in probe process.begin\012";
        function___global_ubacktrace__overload_0 (c);
        if (unlikely(c->last_error || c->aborted)) goto out;
        (void) 0;
      });
      strlcpy (l->l___stable___global_ubacktrace__overload_0_value, l->__tmp0,
MAXSTRINGLEN);
      l->__tmp0;
    });

    if ((((global(s___global_a)) == (((int64_t)1LL))))) {
      goto out;
    }
```

Disabling the optimizations make this issue go away:

```
    if ((((global(s___global_a)) == (((int64_t)1LL))))) {
      c->actionremaining -= 1;
      if (unlikely (c->actionremaining <= 0)) {
        c->last_error = "MAXACTION exceeded";
        c->last_stmt = "keyword at <input>:1:45";
        goto out;
      }
      goto out;
    }

...

    (void)
    ({
      strlcpy (l->__tmp2,
      ({
        function___global_ubacktrace__overload_0 (c);
        if (unlikely(c->last_error || c->aborted)) goto out;
        strlcpy (l->__tmp3,
c->locals[c->nesting+1].function___global_ubacktrace__overload_0.__retvalue,
MAXSTRINGLEN);
        l->__tmp3;
      }), MAXSTRINGLEN);
      #ifndef STP_LEGACY_PRINT
        c->printf_locals.stp_printf_1.arg0 = l->__tmp2;
        stp_printf_1 (c);
      #else // STP_LEGACY_PRINT
        _stp_printf ("%s\n", l->__tmp2);
      #endif // STP_LEGACY_PRINT
      if (unlikely(c->last_error || c->aborted)) goto out;
      ((int64_t)0LL);
    });
```

Seems like an optimization doing code moving is just too aggressive.

I've tested the latest git master version on my side (commit f70d74ef66952).

I've attached the two cases' C files (by -p3) for the reference.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/26392] The optimizer would generate inefficient code which always evaluate dwarf ops eagerly

[agentzh at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26392

agentzh <agentzh at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from agentzh <agentzh at gmail dot com> ---
Committed a fix in commit d4d890cb2. Thanks fche for the help.

-- 
You are receiving this mail because:
You are the assignee for the bug.