public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [tree-ssa] string builtins strikes back
@ 2003-12-11 19:26 Jan Hubicka
  2003-12-15 22:08 ` Richard Henderson
  2004-02-28  2:13 ` law
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Hubicka @ 2003-12-11 19:26 UTC (permalink / raw)
  To: gcc, law

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 0x40194378 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_unit_decl 0x4019615c> attributes <tree_list 0x401d2048>
            (mem:QI (symbol_ref:SI ("strlen") [flags 0x41] <function_decl 0x401d1740 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 0x40194378 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 0x401949a8 -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?

Honza

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] string builtins strikes back
  2003-12-11 19:26 [tree-ssa] string builtins strikes back Jan Hubicka
@ 2003-12-15 22:08 ` Richard Henderson
  2003-12-15 23:32   ` Jan Hubicka
  2004-02-28  2:13 ` law
  1 sibling, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2003-12-15 22:08 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc, law

On Thu, Dec 11, 2003 at 07:11:49PM +0100, Jan Hubicka wrote:
> What would be best to cope with this?

Re-gimplify.


r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] string builtins strikes back
  2003-12-15 22:08 ` Richard Henderson
@ 2003-12-15 23:32   ` Jan Hubicka
  2003-12-15 23:44     ` law
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Hubicka @ 2003-12-15 23:32 UTC (permalink / raw)
  To: Richard Henderson, Jan Hubicka, gcc, law

> On Thu, Dec 11, 2003 at 07:11:49PM +0100, Jan Hubicka wrote:
> > What would be best to cope with this?
> 
> Re-gimplify.

You mean re-gimplify after each fold call? (or just fold_builtins)  Also
we probably need to extend fold_stmt API somewhat to allow it
introducing several statements instead of one (passing around block
iterator and returning pointer to first simplified?)

Honza
> 
> 
> r~

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] string builtins strikes back
  2003-12-15 23:32   ` Jan Hubicka
@ 2003-12-15 23:44     ` law
  2003-12-15 23:56       ` Jan Hubicka
  0 siblings, 1 reply; 6+ messages in thread
From: law @ 2003-12-15 23:44 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: Richard Henderson, Jan Hubicka, gcc

In message <20031215233133.GB19896@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >> On Thu, Dec 11, 2003 at 07:11:49PM +0100, Jan Hubicka wrote:
 >> > What would be best to cope with this?
 >> 
 >> Re-gimplify.
 >
 >You mean re-gimplify after each fold call? (or just fold_builtins)  Also
 >we probably need to extend fold_stmt API somewhat to allow it
 >introducing several statements instead of one (passing around block
 >iterator and returning pointer to first simplified?)
I disagree with Richard's recommendation.  If the folder gives us back
something that is not gimple, then we shouldn't use it -- at least not
at this time, we might want to re-gimplify such things in some cases.

Rather than build the bits to re-gimplify, I'd first look much closer at
why the folder gave us back something which was not gimple.

jeff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] string builtins strikes back
  2003-12-15 23:44     ` law
@ 2003-12-15 23:56       ` Jan Hubicka
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Hubicka @ 2003-12-15 23:56 UTC (permalink / raw)
  To: law; +Cc: Jan Hubicka, Richard Henderson, Jan Hubicka, gcc

> In message <20031215233133.GB19896@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
> s:
>  >> On Thu, Dec 11, 2003 at 07:11:49PM +0100, Jan Hubicka wrote:
>  >> > What would be best to cope with this?
>  >> 
>  >> Re-gimplify.
>  >
>  >You mean re-gimplify after each fold call? (or just fold_builtins)  Also
>  >we probably need to extend fold_stmt API somewhat to allow it
>  >introducing several statements instead of one (passing around block
>  >iterator and returning pointer to first simplified?)
> I disagree with Richard's recommendation.  If the folder gives us back
> something that is not gimple, then we shouldn't use it -- at least not
> at this time, we might want to re-gimplify such things in some cases.
> 
> Rather than build the bits to re-gimplify, I'd first look much closer at
> why the folder gave us back something which was not gimple.

See original mail.  THe problem comes from string strlen folder that
looks up for argument that contains a cast, casts is into sizetype and
cast it back.  We end up with nested expression containing multiple
casts.

Honza
> 
> jeff
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [tree-ssa] string builtins strikes back
  2003-12-11 19:26 [tree-ssa] string builtins strikes back Jan Hubicka
  2003-12-15 22:08 ` Richard Henderson
@ 2004-02-28  2:13 ` law
  1 sibling, 0 replies; 6+ messages in thread
From: law @ 2004-02-28  2:13 UTC (permalink / raw)
  To: Jan Hubicka; +Cc: gcc

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-02-28  1:06 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-11 19:26 [tree-ssa] string builtins strikes back Jan Hubicka
2003-12-15 22:08 ` Richard Henderson
2003-12-15 23:32   ` Jan Hubicka
2003-12-15 23:44     ` law
2003-12-15 23:56       ` Jan Hubicka
2004-02-28  2:13 ` law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).