On Tueday, 14.07.2026 at 15:46, Jeffrey Law wrote:> On 7/14/2026 1:43
AM, Richard Biener wrote:
So given it was just one test affected (on every target), do we want to
try and be more aggressive by enabling the transformation earlier and
fix that one test? Or would you prefer more conservatism here?
jeff
This test failure does seem to at-least be substantive, given that it
represents a missed optimization.
When the transformation is applied early, the call to strlen is removed
before the strlen pass can see it, and thus information about the string
can no longer be gathered. Ordinarily for this test case, the compiler
will see strlen (s) == 0 and use that to turn strcpy into memcpy, but
since the strlen call is removed, it can no longer do so. In an ideal
world, I imagine the compiler should be able to discern the string is
empty given *s == 0, just as with strlen (s) == 0. Moreover, perhaps it
should remove the strcpy of an empty string altogether. Regardless,
without that information, some optimizations will be missed.
Would an "if *s == 0, the string is empty" (or perhaps "if s[i] == 0,
the length of the string is less than or equal to i") analysis in strlen
be feasible to implement? Is it even true? I think whether or not the
last full fold restriction can be lifted comes down to these things.
> I think it's OK to restrict the folding to last forwprop for now. But please
> open a bugreport about strlen missing to recognize *s == 0, the existing
> testcase can be modified to replace strlen(s) == 0 with *s == 0 to show
> an existing issue. When that's fixed we can relax the folding.
I doubt the case tested by strlen-89 appears that often in real world
code, so that plan works for me.
jeff
I've created PR126266 for this purpose.
