public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>,
	GCC Patches	<gcc-patches@gcc.gnu.org>
Cc: nd <nd@arm.com>, Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: [PATCH][ARM] Improve max_insns_skipped logic
Date: Tue, 05 Sep 2017 10:32:00 -0000	[thread overview]
Message-ID: <DB6PR0801MB2053FA6AFF872286A1587DC383960@DB6PR0801MB2053.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <59AD84DE.20601@foss.arm.com>

Kyrill Tkachov wrote:

> I like the simplifications in the selection logic here :)
> However, changing the value for ARM from 6 to 4 looks a bit arbitrary to me.
> There's probably a reason why default values for ARM and Thumb-2 are 
> different
> (maybe not a good one) and I'd rather not change it without some code 
> size data measurements.

To quote myself from the thread:

Long conditional sequences are slow on modern cores - the value 6 for
max_insns_skipped is a few decades out of date as it was meant for ARM2!
Even with -Os the performance loss for larger values is not worth the
small codesize gain (there are many better options to reduce codesize
that actually improve performance at the same time). So using the same
code generation heuristics for ARM and Thumb-2 is a good idea.

A simple codesize comparison on CSiBE shows using 4 rather than 6 for
max_insns_skipped is just 0.07% larger on ARM with -Os. So it's not
obvious that increasing max_insns_skipped in -Os is a useful codesize
optimization...

>So I'd rather not let that hold this cleanup patch though, so this is ok
>  (assuming a normal bootstrap and testing cycle) without changing the 6 
> to a 4
> and you can propose a change to 4 as a separate patch that can be 
> discussed on its own.

Based on the above is that really needed? What specific problem do you
expect to occur with the value 4? 

Wilco

    

  reply	other threads:[~2017-09-05 10:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10 17:19 Wilco Dijkstra
2016-11-11 10:32 ` Richard Earnshaw
2016-11-11 11:42   ` Wilco Dijkstra
2016-11-14 14:15     ` Wilco Dijkstra
2016-12-06 15:05 ` Wilco Dijkstra
2016-12-14 16:39   ` Wilco Dijkstra
2017-01-17 12:16     ` Wilco Dijkstra
2017-02-02 14:45       ` Wilco Dijkstra
2017-02-23 16:58         ` Wilco Dijkstra
2017-04-20 16:05 ` Wilco Dijkstra
2017-06-13 14:00   ` Wilco Dijkstra
2017-06-27 15:38     ` Wilco Dijkstra
2017-09-04 16:52       ` Kyrill Tkachov
2017-09-05 10:32         ` Wilco Dijkstra [this message]
2017-09-05 17:16           ` Kyrill Tkachov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB6PR0801MB2053FA6AFF872286A1587DC383960@DB6PR0801MB2053.eurprd08.prod.outlook.com \
    --to=wilco.dijkstra@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kyrylo.tkachov@foss.arm.com \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).