Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-02 Thread Jeff Law
On 12/02/2016 03:22 PM, Segher Boessenkool wrote: On Fri, Dec 02, 2016 at 09:47:00AM +0100, Richard Biener wrote: STC tries to make as large as possible consecutive "traces", mainly to help with instruction cache utilization and hit rate etc. It cannot do a very good job if it isn't allowed to

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-02 Thread Segher Boessenkool
On Fri, Dec 02, 2016 at 09:47:00AM +0100, Richard Biener wrote: > >> STC tries to make as large as possible consecutive "traces", mainly to > >> help with instruction cache utilization and hit rate etc. It cannot do > >> a very good job if it isn't allowed to copy blocks. > >> > >> "simple" tries

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-02 Thread Richard Biener
On Thu, Dec 1, 2016 at 6:28 PM, Jeff Law wrote: > On 12/01/2016 05:04 AM, Segher Boessenkool wrote: >> >> On Thu, Dec 01, 2016 at 10:19:42AM +0100, Richard Biener wrote: > > Thinking about this again maybe targets w/o insn-length should simply > always use the

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-01 Thread Jeff Law
On 12/01/2016 05:04 AM, Segher Boessenkool wrote: On Thu, Dec 01, 2016 at 10:19:42AM +0100, Richard Biener wrote: Thinking about this again maybe targets w/o insn-length should simply always use the 'simple' algorithm instead of the STV one? At least that might be what your change effectively

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-01 Thread Segher Boessenkool
On Thu, Dec 01, 2016 at 10:19:42AM +0100, Richard Biener wrote: > >> Thinking about this again maybe targets w/o insn-length should simply > >> always use the 'simple' algorithm instead of the STV one? At least that > >> might be what your change effectively does in some way? > > > > From reading

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-12-01 Thread Richard Biener
On Wed, Nov 30, 2016 at 6:59 PM, Jeff Law wrote: > On 11/30/2016 01:38 AM, Richard Biener wrote: >> >> On Tue, Nov 29, 2016 at 5:07 PM, Jeff Law wrote: >>> >>> On 11/29/2016 03:23 AM, Richard Biener wrote: On Mon, Nov 28, 2016 at 10:23 PM, Jeff

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-11-30 Thread Jeff Law
On 11/30/2016 01:38 AM, Richard Biener wrote: On Tue, Nov 29, 2016 at 5:07 PM, Jeff Law wrote: On 11/29/2016 03:23 AM, Richard Biener wrote: On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote: I was digging into issues around the patches for 78120 when I

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-11-30 Thread Richard Biener
On Tue, Nov 29, 2016 at 5:07 PM, Jeff Law wrote: > On 11/29/2016 03:23 AM, Richard Biener wrote: >> >> On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote: >>> >>> >>> >>> I was digging into issues around the patches for 78120 when I stumbled >>> upon >>>

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-11-29 Thread Jeff Law
On 11/29/2016 03:23 AM, Richard Biener wrote: On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote: I was digging into issues around the patches for 78120 when I stumbled upon undesirable bb copying in bb-reorder.c on the m68k. The core issue is that the m68k does not define a

Re: [RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-11-29 Thread Richard Biener
On Mon, Nov 28, 2016 at 10:23 PM, Jeff Law wrote: > > > I was digging into issues around the patches for 78120 when I stumbled upon > undesirable bb copying in bb-reorder.c on the m68k. > > The core issue is that the m68k does not define a length attribute and > therefore

[RFA] Handle target with no length attributes sanely in bb-reorder.c

2016-11-28 Thread Jeff Law
I was digging into issues around the patches for 78120 when I stumbled upon undesirable bb copying in bb-reorder.c on the m68k. The core issue is that the m68k does not define a length attribute and therefore generic code assumes that the length of all insns is 0 bytes. That in turn