This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GCC] Simplification of 1U << (31 - x)
- From: Sudi Das <Sudi dot Das at arm dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, James Greenhalgh <James dot Greenhalgh at arm dot com>
- Date: Fri, 6 Oct 2017 17:00:30 +0000
- Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Sudi dot Das at arm dot com;
- Nodisclaimer: True
- References: <AM5PR0802MB2610B3E04DF2484B04208CEC83020@AM5PR0802MB2610.eurprd08.prod.outlook.com> <20170413112151.GD1809@tucnak> <AM5PR0802MB2610B75CC3BDBA5C021B3DA083020@AM5PR0802MB2610.eurprd08.prod.outlook.com> <20170413114125.GE1809@tucnak> <CAFiYyc1Jk2hpuw1xnGD98SNQzzQHTzaoxFhq5C0ZeJVvZ2hODw@mail.gmail.com> <AM5PR0802MB2610D2CFF2BC0E6DF5E9093683020@AM5PR0802MB2610.eurprd08.prod.outlook.com> <VI1PR08MB265576266CC24A0553CCB94898B30@VI1PR08MB2655.eurprd08.prod.outlook.com> <CAFiYyc0C79=vcjFN7e=uZZVHjORMoOyUpyo3rYd_H9XTPHoG6w@mail.gmail.com> <DB5PR08MB10484FE2601E338FC2E68208987B0@DB5PR08MB1048.eurprd08.prod.outlook.com>,<20170926130612.GR1701@tucnak>,<DB6PR0801MB20539B7B838C5207003EB37F837B0@DB6PR0801MB2053.eurprd08.prod.outlook.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
Hi Jakub
As per the discussions, I have a created a bug report for the possible regression this may cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82454
Sudi
From: Wilco Dijkstra
Sent: Tuesday, September 26, 2017 2:20 PM
To: Sudi Das; Jakub Jelinek
Cc: Richard Biener; GCC Patches; nd; Richard Earnshaw; James Greenhalgh
Subject: Re: [PATCH][GCC] Simplification of 1U << (31 - x)
Jakub Jelinek wrote:
> Well, we don't want to regress performance wise on one of the most important
> primary targets. I don't care that much if the RTL/backend work is done
> together with the patch, or as a follow-up during stage1/3, but it should be
> done, the testcases I've posted can be used as a basis of a P1 runtime
> performance regression.
It should be sufficient to file a bug about inefficient 64-bit constant expansions on
x64. I didn't see a significant difference in my benchmarking of it on x64, so I'd say
it's only a performance regression if large benchmarks regress measurably (quite
unlikely).
Wilco