[Bug tree-optimization/86259] [8/9 Regression] min(4, strlen(s)) optimized to strlen(s) with -flto

[msebor at gcc dot gnu.org]

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

--- Comment #30 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #28)
> 
> Can someone explain why the example in comment #21 works when
> pointer arithmentic instead of integer arithmetic is used?

Because the optimization (making use of the size of the referenced array)
doesn't apply in the pointer case.  In the integer case, ccp simplifies the
strlen argument to a COMPONENT_REF:

  Visiting statement:
  _2 = sp_ip_9 + 4;
  which is likely CONSTANT
  Match-and-simplified sp_ip_9 + 4 to bp.0_1
  Lattice value changed to CONSTANT bp.0_1.  Adding SSA edges to worklist.
  marking stmt to be not simulated again

  Visiting statement:
  _3 = (const char *) _2;
  which is likely CONSTANT
  Match-and-simplified (const char *) _2 to &u.s.b
  Lattice value changed to CONSTANT &u.s.b.  Adding SSA edges to worklist.
  marking stmt to be not simulated again

The COMPONENT_REF fully describes the structure of an access to a member and so
lends itself to interesting analysis which then opens up opportunities for both
optimization and bug detection (e.g., buffer overflow).

In the pointer case ccp replaces the argument with with a MEM_REF:

  Visiting statement:
  _1 = sp_ip_7 + 4;
  which is likely CONSTANT
  Lattice value changed to CONSTANT &MEM[(void *)&u + 4B].  Adding SSA edges to
worklist.
  marking stmt to be not simulated again

A ME_REF is a concise but low-level way of referencing memory via a base
address an an offset.  It doesn't include reliable information about the
structure of the referenced memory.  It's easier to do some basic things with
but much harder to use for interesting, higher level analysis.  By folding
expressions into MEM_REF early on, GCC effectively disables subsequent
optimizations that are designed to do interesting things at a higher level.