[Bug tree-optimization/98176] Loop invariant memory could not be hoisted when nonpure_call in loop body

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2020-12-08 00:00:00         |2021-7-7

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I've just pushed the change g:9f34b780b0461ec7b2b2defe96e44ab616ea2aa3 which
allows store-motion to handle some unanalyzed refs (but not yet calls because I
wanted a testcase showing usefulness).

I'm failing to reproduce with the sincos example since sincos is transformed
to __builtin_cexpi for me.  When using

float frexpf(float x, int *exp);
float foo(int *x, int n, float tx)
{
        float ret[n];
        int exp; 
        for (int i = 0; i < n; i++)
          ret[0] += frexpf (tx, &exp);
        return ret[0];
}

as alternate example we are not able to move ret[] as it seems we consider
the access to not always happen since it seems we consider frexpf possibly
not returning because it's a non-pure call:

/* Fills ALWAYS_EXECUTED_IN information for basic blocks, i.e.
   for each such basic block bb records the outermost loop for that execution
   of its header implies execution of bb.  */

static void
fill_always_executed_in (void)
{
  basic_block bb;
  class loop *loop;

  auto_sbitmap contains_call (last_basic_block_for_fn (cfun));
  bitmap_clear (contains_call);
  FOR_EACH_BB_FN (bb, cfun)
    {
      gimple_stmt_iterator gsi;
      for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
        {
          if (nonpure_call_p (gsi_stmt (gsi)))
            break;
        }

      if (!gsi_end_p (gsi))
        bitmap_set_bit (contains_call, bb->index);
    }

  for (loop = current_loops->tree_root->inner; loop; loop = loop->next)
    fill_always_executed_in_1 (loop, contains_call);
}

so I don't think it buys us anything to handle calls yet.  sincos would
also be considered as possibly not returning.

I don't think we have any IPA analysis helping us here (yet).