Re: About loop unrolling and optimize for size
I just tried both -Os -fpeel-loops and -Os -frename-registers for a code I'm trying to compact, and both settings increased code size compared to -Os. cheers simon On 08/14/2015 11:53 AM, sa...@hederstierna.com wrote: > I think I found explanation, the -fpeel-loops trigger some extra flags: > > from "toplev.c": > > /* web and rename-registers help when run after loop unrolling. */ > if (flag_web == AUTODETECT_VALUE) > flag_web = flag_unroll_loops || flag_peel_loops; > > if (flag_rename_registers == AUTODETECT_VALUE) > flag_rename_registers = flag_unroll_loops || flag_peel_loops; > > actually its -frename-registers that causes the code size to decrease. > This flags seems to be set when enable -fpeel-loops. > > Maybe this flag could be enabled in -Os, shouldn't have any downside besides > makes possibly debugging harder? > > Thanks/Fredrik > > > > From: Richard Biener [richard.guent...@gmail.com] > Sent: Friday, August 14, 2015 09:28 > To: sa...@hederstierna.com > Cc: gcc@gcc.gnu.org > Subject: Re: About loop unrolling and optimize for size > > On Thu, Aug 13, 2015 at 6:26 PM, sa...@hederstierna.com > wrote: >> Hi >> I'm using an ARM thumb cross compiler for embedded systems and always do >> optimize for small size with -Os. >> >> Though I've experimented with optimization flags, and loop unrolling. >> >> Normally loop unrolling is always bad for size, code is duplicated and size >> increases. >> >> Though I discovered that in some special cases where the number of iteration >> is very small, eg a loop of 2-3 times, >> in this case an unrolling could make code size smaller - eg. losen up >> registers used for index in loops etc. >> >> Example when I use the flag "-fpeel-loops" together with -Os I will 99% of >> the cases get smaller code size for ARM thumb target. >> >> Some my question is how unrolling works with -Os, is it always totally >> disabled, >> or are there some cases when it could be tested, eg. with small number >> iterations, so loop can be eliminated? >> >> Could eg. "-fpeel-loops" be enabled by default for -Os perhaps? Now its only >> enabled for -O2 and above I think. > Complete peeling is already enabled with -Os, it is just restricted to > those cases where GCCs cost modeling of the > unrolling operation determines the code size shrinks. If you enable > -fpeel-loops then the cost model allows the > code size to grow - sth not (always) intended with -Os. > > The solution is of course to improve the cost modeling and GCCs idea > of followup optimization opportunities. > I do have some incomplete patches to improve that and hope to get back > to it for GCC 6. > > If you have (small) testcases that show code size improvements with > -Os -fpeel-loops over -Os and you are > confident they are caused by unrolling please open a bugzilla containing them. > > Thanks, > Richard. > >> Thanks and Best Regards >> Fredrik signature.asc Description: OpenPGP digital signature
Re: Optimization bug?
On Sun, 2015-09-20 at 08:38AM +0200, Richard Biener wrote:
> On September 20, 2015 1:40:12 AM GMT+02:00, Martin Sebor
> wrote:
> >On 09/19/2015 03:32 PM, Sören Brinkmann wrote:
> >> Hi Andrew,
> >>
> >> On Sat, 2015-09-19 at 11:34AM -0700, pins...@gmail.com wrote:
> >>>
> >>>
> On Sep 19, 2015, at 11:00 AM, Sören Brinkmann
> > wrote:
>
> Hi,
>
> I recently came across some bug in my program that I could narrow
> >down
> to the snipped below (also attached with a Makefile).
>
> extern unsigned int _vector_table;
> >>>
> >>> You need the attribute weak here if the location of _vector_table
> >can be a null pointer.
> >>
> >> Indeed, that fixes the problem. Would you have any additional
> >background
> >> why the 'weak' is required in this case? To me it sounded like the
> >> '-fno-delete-null-pointer-checks' should be sufficient.
> >
> >-fno-delete-null-pointer-checks prevents GCC from removing tests
> >for null pointers after such pointers have been dereferenced. For
> >example, in the following function, GCC normally eliminates the
> >second if statement because the first statement lets it assume
> >that p is not null (otherwise dereferencing it would be undefined).
> >
> > int foo (int *p) {
> > if (*p == 0) return 0;
> > if (p == 0) return 1;
> > return 2;
> > }
> >
> >The option doesn't affect other assumptions such as that every
> >object and function in a program lives at a valid, non-null
> >address.
>
> Actually we abuse this flag for exactly this purpose so I think the testcase
> shows a bug. Unless the particular target cannot have global vars at address
> zero.
>
> Would you mind opening a bugreport?
Not at all. You can find it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67651
Thanks,
Sören
Re: Optimization bug?
On 09/20/2015 12:38 AM, Richard Biener wrote:
On September 20, 2015 1:40:12 AM GMT+02:00, Martin Sebor
wrote:
On 09/19/2015 03:32 PM, Sören Brinkmann wrote:
Hi Andrew,
On Sat, 2015-09-19 at 11:34AM -0700, pins...@gmail.com wrote:
On Sep 19, 2015, at 11:00 AM, Sören Brinkmann
wrote:
Hi,
I recently came across some bug in my program that I could narrow
down
to the snipped below (also attached with a Makefile).
extern unsigned int _vector_table;
You need the attribute weak here if the location of _vector_table
can be a null pointer.
Indeed, that fixes the problem. Would you have any additional
background
why the 'weak' is required in this case? To me it sounded like the
'-fno-delete-null-pointer-checks' should be sufficient.
-fno-delete-null-pointer-checks prevents GCC from removing tests
for null pointers after such pointers have been dereferenced. For
example, in the following function, GCC normally eliminates the
second if statement because the first statement lets it assume
that p is not null (otherwise dereferencing it would be undefined).
int foo (int *p) {
if (*p == 0) return 0;
if (p == 0) return 1;
return 2;
}
The option doesn't affect other assumptions such as that every
object and function in a program lives at a valid, non-null
address.
Actually we abuse this flag for exactly this purpose so I think the testcase
shows a bug. Unless the particular target cannot have global vars at address
zero.
Would you mind opening a bugreport?
I'm not sure I follow. I've tested the original example with 6.0,
5.1, 4.9, 4.8.3, and 4.8.1. All of these eliminate the test with
-fno-delete-null-pointer-checks. Are you saying that's a bug? If
so, what version retains the test?
Martin
gcc-6-20150920 is now available
Snapshot gcc-6-20150920 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20150920/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 227952 You'll find: gcc-6-20150920.tar.bz2 Complete GCC MD5=739c32fe412f035e8f3502ce84165633 SHA1=99037f6e52a41332c07b04fd00b66779bd4c01d8 Diffs from 6-20150913 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Deprecate SH5/SH64
On Tue, 2015-08-18 at 12:41 -0600, Jeff Law wrote: > On 08/18/2015 11:11 AM, David Edelsohn wrote: > > On Tue, Aug 18, 2015 at 1:00 PM, Oleg Endo > > wrote: > >> Hi all, > >> > >> Kaz and I have been discussing the SH5/SH64 status, which is part > >> of the SH port, every now and then. To our knowledge, there is no > >> real hardware available as of today and we don't think there are > >> any real users for a SH5/SH64 toolchain out there. Moreover, the > >> SH5/SH64 parts of the SH port haven't been touched by anybody for a > >> long time. The only exception is occasional ad-hoc fixes for bug > >> reports from people who build GCC for every architecture that is > >> listed in the Linux kernel. However, we don't actually know > >> whether code compiled for SH5/SH64 still runs at an acceptable > >> level since nobody has been doing any testing for that architecture > >> for a while now. > >> > >> If there are no objections, we would like to deprecate SH5/SH64 > >> support as of GCC 6. > >> > >> Initially this would include an announcement on the changes page > >> and the removal of any documentation related to SH5/SH64. After > >> GCC 6 we might start removing configure options and the respective > >> code paths in the target. > > > > +1 > Works for me based on what I've heard independently about sh5 hardware > situation. > > > Frankly, I think we should be more aggressive about this kind of > port/variant pruning across the board. I have committed the announcement for the GCC 6 page https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html Cheers, Oleg
Multiprecision Arithmetic Builtins
Hi all, I was thinking of adding some SH specific builtin functions for the addc, subc and negc instructions. Are there any plans to add clang's target independent multiprecision arithmetic builtins (http://clang.llvm.org/docs/LanguageExtensions.html) to GCC? A while ago clang's checked arithmetic builtins were added to GCC. So just in case, I wanted to check before introducing target specific builtins. Cheers, Oleg
