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
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
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 'simple' algorithm instea
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 d
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
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 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 Law wrote:
I was digging into issues around the patches for 78120 when I stumbled
upon
undesirable bb copyi
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
>>> undesirable bb copying in bb-reorder.c on t
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 length attribute
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 generic code assumes tha
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 makes
11 matches
Mail list logo