On Thu, May 16, 2013 at 10:33:27PM +0200, Jakub Jelinek wrote:
> On Thu, May 16, 2013 at 06:44:03PM +0200, Marek Polacek wrote:
> > --- gcc/tree-ssa-strlen.c.mp2013-05-15 14:11:20.079707492 +0200
> > +++ gcc/tree-ssa-strlen.c 2013-05-16 17:57:33.963150006 +0200
> > @@ -1693,8 +1693,10 @@
On Thu, May 16, 2013 at 06:44:03PM +0200, Marek Polacek wrote:
> --- gcc/tree-ssa-strlen.c.mp 2013-05-15 14:11:20.079707492 +0200
> +++ gcc/tree-ssa-strlen.c 2013-05-16 17:57:33.963150006 +0200
> @@ -1693,8 +1693,10 @@ handle_char_store (gimple_stmt_iterator
> }
> els
On Thu, May 16, 2013 at 04:28:19PM +0200, Jakub Jelinek wrote:
> On Thu, May 16, 2013 at 04:18:27PM +0200, Jakub Jelinek wrote:
> > As q could point to p, if we didn't do what your patch does on the p[0] =
> > 'X';
> > store, then we'd need to invalidate the recorded length of the q string.
> > Si
On Thu, May 16, 2013 at 04:18:27PM +0200, Jakub Jelinek wrote:
> As q could point to p, if we didn't do what your patch does on the p[0] = 'X';
> store, then we'd need to invalidate the recorded length of the q string.
> Similarly if there is p[0] = '\0' or p[0] = var.
Ah, another thing while we a
On Thu, May 16, 2013 at 04:07:44PM +0200, Marek Polacek wrote:
> --- gcc/tree-ssa-strlen.c.mp 2013-05-15 14:11:20.079707492 +0200
> +++ gcc/tree-ssa-strlen.c 2013-05-16 16:03:50.373504796 +0200
> @@ -1717,6 +1717,27 @@ handle_char_store (gimple_stmt_iterator
> si->endptr = ssaname;
>
On Thu, May 16, 2013 at 03:38:47PM +0200, Jakub Jelinek wrote:
> Please add here a comment what it does and why, that if si->length
> is non-zero constant, we know that the character at that spot is
> not '\0' and when storing non-'\0' to that location, we can't affect
> size of any strings at all.
On Thu, May 16, 2013 at 03:31:40PM +0200, Marek Polacek wrote:
> Cool, I took the gsi_next approach; seems to work nicely. So, updated
> version (it still doesn't handle p[1], p[2], etc.).
>
> Regtested/bootstrapped on x86_64-linux.
>
> 2013-05-16 Marek Polacek
>
> * tree-ssa-strlen.c
On Wed, May 15, 2013 at 07:20:03PM +0200, Jakub Jelinek wrote:
> Well, if si->length is known constant != 0 (note, it is enough to
> test that it is non-zero and probably the code above this has
> tested that already?) and we are storing non-zero, then that
> should mean we are overwriting a non-ze
On Thu, May 16, 2013 at 10:54:53AM +0200, Richard Biener wrote:
> Can we properly distinguish the case of
>
> char *s = "Hello\0World!";
> s[5] = ' ';
>
> (minor the imperfections in that example)? Thus, overwriting the terminating
> 0?
I think so. Because then for &s[5], either si should
On Wed, May 15, 2013 at 7:20 PM, Jakub Jelinek wrote:
> On Wed, May 15, 2013 at 06:59:09PM +0200, Marek Polacek wrote:
>> This is a strlen opt patch that better optimizes attached testcase;
>> there's just no need to call strlen again, as we're not changing
>> the length of the string. Unfortunat
On Wed, May 15, 2013 at 06:59:09PM +0200, Marek Polacek wrote:
> This is a strlen opt patch that better optimizes attached testcase;
> there's just no need to call strlen again, as we're not changing
> the length of the string. Unfortunately this still handles only
> p[0], not for instance p[1], p
This is a strlen opt patch that better optimizes attached testcase;
there's just no need to call strlen again, as we're not changing
the length of the string. Unfortunately this still handles only
p[0], not for instance p[1], p[2], ... so we likely don't want to put
this in now. But I'm posting i
12 matches
Mail list logo
