Re: [tree-ssa] string builtins strikes back

[law at redhat dot com]

In message <20031211181149.GB27614@kam.mff.cuni.cz>, Jan Hubicka writes:
 >Hi,
 >the folling testcase (derived from testsuite):
 >
 >extern void abort (void);
 >extern __SIZE_TYPE__ strlen (const char *);
 >
 >int x = 6;
 >
 >void
 >main_test (void)
 >{
 >  const char *const foo = "hello world";
 >
 >  if (strlen (foo + (x++ & 7)) != 5)
 >    abort ();
 >}
 >Causes fold_stmt to turn gimple:
 > <call_expr 0x40195678
 >    type <integer_type 0x40196570 unsigned int unsigned SI
 >        size <integer_cst 0x40194288 constant invariant 32>
 >        unit size <integer_cst 0x40194330 constant invariant 4>
 >        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0x401943
 >78 0> max <integer_cst 0x40194390 4294967295>>
 >    nothrow
 >    arg 0 <addr_expr 0x401a45e0
 >        type <pointer_type 0x40267570 type <function_type 0x401d16cc>
 >            unsigned SI
 >            size <integer_cst 0x40194978 constant invariant 32>
 >            unit size <integer_cst 0x401949d8 constant invariant 4>
 >            align 32 symtab 0 alias set -1>
 >        constant invariant
 >        arg 0 <function_decl 0x40264740 strlen type <function_type 0x401d16cc
 >>
 >            addressable used nothrow public external built-in defer-output QI
 > file a.c line 2
 >            built-in BUILT_IN_NORMAL:BUILT_IN_STRLEN context <translation_uni
 >t_decl 0x4019615c> attributes <tree_list 0x401d2048>
 >            (mem:QI (symbol_ref:SI ("strlen") [flags 0x41] <function_decl 0x4
 >01d1740 strlen>) [0 S1 A8]) chain <function_decl 0x40264984 strcmp>>>
 >    arg 1 <tree_list 0x40266930
 >        value <ssa_name 0x40266cf0 type <pointer_type 0x4026732c>
 >           >>
 >    a.c:15>
 >
 >Into non-gimple:
 > <nop_expr 0x4026a000
 >    type <integer_type 0x40196570 unsigned int unsigned SI
 >        size <integer_cst 0x40194288 constant invariant 32>
 >        unit size <integer_cst 0x40194330 constant invariant 4>
 >        align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0x401943
 >78 0> max <integer_cst 0x40194390 4294967295>>
 >
 >    arg 0 <minus_expr 0x401959d8
 >        type <integer_type 0x4019d89c sizetype SI
 >            size <integer_cst 0x40194978 constant invariant 32>
 >            unit size <integer_cst 0x401949d8 constant invariant 4>
 >            align 32 symtab 0 alias set -1 precision 32 min <integer_cst 0x40
 >1949a8 -2147483648> max <integer_cst 0x401949c0 2147483647>>
 >
 >        arg 0 <integer_cst 0x402668a0 constant invariant 11>
 >        arg 1 <nop_expr 0x401a4fa0 type <integer_type 0x4019d89c>
 >
 >            arg 0 <ssa_name 0x40266cd8 type <integer_type 0x40196570 unsigned
 > int>
 >               >>>>
 >
 >What would be best to cope with this?  (in this case proper folding of nops
 >would elliminate them) but in general I don't think this is possible in all
 >side cases of string builtins.
 >Do we want the fold_stmt to produce possibly multiple statement when this
 >simplifies things down?  What should be the interface here?
Long term we might want to produce multiple statements, but for now I think
simply rejecting substitutions when doing so would create non-gimple code
is the right thing to do.

I've checked in a patch to fix this instance as well as a handful of others
that I found during a bootstrap & regression test.    I also checked in
the enhanced statement checking code to help detect this losing behavior.
It shall be interesting to see if any others pop up in wider testing.  I'm
particularly worried about the builtin simplifications.

jeff