On 08/04/2017 06:59 AM, Prathamesh Kulkarni wrote:
Hi,
I was having a look at PR78809.
For the test-case:
int t1(const char *s) { return __builtin_strcmp (s, "a"); }
for aarch64, trunk with -O2 generates:
t1:
adrp x1, .LANCHOR0
add x1, x1, :lo12:.LANCHOR0
b strcmp
For i386, it seems strcmp is expanded inline via cmpstr optab by
expand_builtin_strcmp
if one of the strings is constant. Could we similarly define cmpstr
pattern for AArch64 ?
For constant strings of small length (upto 3?), I was wondering if
it'd be a good idea to
manually unroll strcmp loop, similar to __strcmp_* macros in bits/string.h ?
For eg in gimple-fold, transform
x = __builtin_strcmp(s, "ab")
to
x = s[0] - 'a';
if (x == 0)
{
x = s[1] - 'b';
if (x == 0)
x = s[2];
}
IMO, in general, it's better do this sort of expansion into "low
level" code late, after higher-level optimizations have been done.
Otherwise it can defeat such optimizations in passes that aren't
prepared to handle the low level code. For instance, in the
following, the call to strcmp could readily be eliminated in
tree-ssa-strlen because the pass knows both of the strings being
compared. But if the strcmp() call were expanded as you show above
the optimization couldn't be implemented nearly as easily (not
without essentially undoing the work previously done by the folder).
void f (char *s)
{
strcpy (s, "a");
if (strcmp (s, "ab") > 0)
abort ();
}
Not only that, unless all the arguments are known, the early
expansion can also defeat checks for their validity. For example,
in strcmp (a, b), if a and b point to the same non-null terminated
or even uninitialized) array the call is folded into zero without
a warning. If/when tree-ssa-strlen (or some other pass) is enhanced
to detect such invalid strings this bug could be easily detected but
only as long as strcmp call makes it to the pass untransformed.
Martin
PS The examples above are only hypothetical because tree-ssa-
strlen doesn't at present handle strcmp. Bugs 81703 and
81704 are examples where folding does get in the way today.
