From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29253 invoked by alias); 7 Jun 2014 09:12:20 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 29206 invoked by uid 48); 7 Jun 2014 09:12:13 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/55583] Extended shift instruction on x86-64 is not used, producing unoptimal code Date: Sat, 07 Jun 2014 09:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-06/txt/msg00528.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55583 Marc Glisse changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2012-12-04 00:00:00 |2014-6-7 --- Comment #6 from Marc Glisse --- Several things: 1) https://gcc.gnu.org/ml/gcc/2014-06/msg00063.html points out that our shrd patterns wrongly use ashiftrt instead of lshiftrt 2) We can convince the current compiler to generate shrd by constructing ((((unsigned long long)a)<<32) | b) >> n (take care not to use '+' in place of '|' because gcc is unable to realize that x+0 has no carry and thus leaves plenty of unneeded code in that case). For a constant shift, it manages to clean up all the useless code. At least that works for the 32 bit version with -m32 and the 64 bit version (using unsigned __int128) with -m64, it doesn't work for the 32 bit version with -m64. 3) With extra patterns as attached here, combine can handle the case where the shift amount is constant. However, the non-constant pattern is too big for combine. The closest it gets to matching is (b<>(l-n)), but replacing l with 32 is one more substitution than it is willing to try (it also ignores the REG_EQUAL note that would give (32-n) with one substitution less). Improving combine would be nice. I am not sure what intermediate pattern (not too artificial) we could introduce to help it. Maybe a>>(32-n), though I don't even know if it is better to implement that as a subtraction and a shift or as generating zero then using sh[lr]d.