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

            Bug ID: 117282
           Summary: Miss optimization to eliminate strlen computation
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxue at os dot amperecomputing.com
  Target Milestone: ---

GCC could handle elimination of strlen call if its result is only used as a
boolean flag, like:

void foo(char *s)
{
    if (strlen(s))
        printf("OK\n");
}

But it fails to do similar strength reduction on a loop that explicitly
implements the semantics of strlen computation, here are some examples:

void foo(char *s)
{
    char *t;

    for (t = s; ; t++) {
        if (!*t)
            break;
    }

    if (t != s)
        printf("OK\n");

}

void foo(char *s)
{
    int i;

    for (i = 0; i < 10000; i++) {
        if (!s[i])
            break;
    }

    if (i)
        printf("OK\n");
}

Besides, it seems to be a common usage that strlen's result would be cast to
"int" or "unsigned int". Since such conversion might involves non-trivial
integer truncation, the above elimination should not be applied for sure.

void foo(char *s)
{
    if ((unsigned)strlen(s))  // strlen is not eliminable
        printf("OK\n");
}

Normally, with workload in reality, a string or data object would not be super
large, for which measurement up to gigabytes would be rare case. So the
conversion would not introduce alteration of result, could be ignored regarding
the elimination.

Currently, gcc has a code-model option -mcmodel, which specifies scale of
data/text segment. Is it feasible that we rely on this option to peel away
conversion losslessly in this optimization? If so, there is one point that
needs to be clearly defined or extended. 

Take aarch64 for example, given -mcmodel=small, it only states that static data
is within 4G bytes. However, for such kind of small application, it could
allocate a dynamic data at runtime exceeding 4G, which is not only possible,
but also common-seen. 

To target the subtle difference around here, could we introduce a new option
like -mcmodel-dyn{=tiny/small/large} as a supplement to -mcmodel, which says
that dynamic data object has limit constraint in the similar way of -mcmodel,
its default value is unlimited {=large)?

Reply via email to