On Mon, 14 Jul 2014, Richard Biener wrote:
> On Fri, 11 Jul 2014, Jakub Jelinek wrote:
>
> > On Fri, Jul 11, 2014 at 03:36:15PM +0200, Richard Biener wrote:
> > > *** c_strlen (tree src, int only_value)
> > > *** 606,612
> > >
> > > /* If the offset is known to be out of b
On Fri, 11 Jul 2014, Jakub Jelinek wrote:
> On Fri, Jul 11, 2014 at 03:36:15PM +0200, Richard Biener wrote:
> > *** c_strlen (tree src, int only_value)
> > *** 606,612
> >
> > /* If the offset is known to be out of bounds, warn, and call strlen at
> >runtime. */
>
On Fri, Jul 11, 2014 at 03:36:15PM +0200, Richard Biener wrote:
> *** c_strlen (tree src, int only_value)
> *** 606,612
>
> /* If the offset is known to be out of bounds, warn, and call strlen at
>runtime. */
> ! if (offset < 0 || offset > max)
> {
>
On Fri, 11 Jul 2014, Richard Biener wrote:
> On Thu, 10 Jul 2014, Jakub Jelinek wrote:
>
> > On Thu, Jul 10, 2014 at 04:30:13PM +0200, Richard Biener wrote:
> > > Compromise "hack" below. It simply avoids the transform for
> > > sources that c_strlen can compute a length of. That "fixes" all
>
On Thu, 10 Jul 2014, Jakub Jelinek wrote:
> On Thu, Jul 10, 2014 at 04:30:13PM +0200, Richard Biener wrote:
> > Compromise "hack" below. It simply avoids the transform for
> > sources that c_strlen can compute a length of. That "fixes" all
> > strlenopt testcase apart from strlenopt-8.c which do
On Thu, Jul 10, 2014 at 04:30:13PM +0200, Richard Biener wrote:
> Compromise "hack" below. It simply avoids the transform for
> sources that c_strlen can compute a length of. That "fixes" all
> strlenopt testcase apart from strlenopt-8.c which does
> memcpy (, flag ? "a" : "b"); which then still
On Fri, 27 Jun 2014, Richard Biener wrote:
> On Fri, 27 Jun 2014, Jakub Jelinek wrote:
>
> > On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> > > I'm going to go for a single load/store and MOVE_MAX for now - I
> > > have quite some fallout to deal with anyway (analyzed strlenopt
On 06/27/14 05:56, Jakub Jelinek wrote:
On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
I'm going to go for a single load/store and MOVE_MAX for now - I
have quite some fallout to deal with anyway (analyzed strlenopt-1.c
FAIL only, the other strlenopt cases are probably similar)
On Fri, 27 Jun 2014, Jakub Jelinek wrote:
> On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> > I'm going to go for a single load/store and MOVE_MAX for now - I
> > have quite some fallout to deal with anyway (analyzed strlenopt-1.c
> > FAIL only, the other strlenopt cases are prob
On Fri, Jun 27, 2014 at 01:49:38PM +0200, Richard Biener wrote:
> I'm going to go for a single load/store and MOVE_MAX for now - I
> have quite some fallout to deal with anyway (analyzed strlenopt-1.c
> FAIL only, the other strlenopt cases are probably similar)
>
> FAIL: gcc.dg/strlenopt-1.c scan-
On Thu, 12 Jun 2014, Jeff Law wrote:
> On 06/12/14 04:12, Richard Biener wrote:
> >
> > This implements the requested inlining of memmove for possibly
> > overlapping arguments by doing first all loads and then all stores.
> > The easiest place is to do this in memory op folding where we already
On 06/12/14 04:12, Richard Biener wrote:
This implements the requested inlining of memmove for possibly
overlapping arguments by doing first all loads and then all stores.
The easiest place is to do this in memory op folding where we already
perform inlining of some memcpy cases (but fail to do
This implements the requested inlining of memmove for possibly
overlapping arguments by doing first all loads and then all stores.
The easiest place is to do this in memory op folding where we already
perform inlining of some memcpy cases (but fail to do the equivalent
memcpy optimization - though
13 matches
Mail list logo
