From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23599 invoked by alias); 30 Apr 2010 19:00:57 -0000 Received: (qmail 23466 invoked by uid 48); 30 Apr 2010 19:00:41 -0000 Date: Fri, 30 Apr 2010 19:00:00 -0000 Message-ID: <20100430190041.23464.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/43883] missed optimization of constant __int128_t modulus In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ubizjak at gmail dot com" 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 X-SW-Source: 2010-04/txt/msg03392.txt.bz2 ------- Comment #5 from ubizjak at gmail dot com 2010-04-30 19:00 ------- (In reply to comment #4) > Argh, the sar trick doesn't work when the number is negative and even. Sorry > about the extra noise. > > This leaves as the best code: > mov %rsi,%rdx > shr $0x3f,%rdx > lea (%rdi,%rdx,1),%rax > and $0x1,%eax > sub %rdx,%rax > sbb %rdx,%rdx > > This is still better than current version. Of course, changing the and > instruction will allow faster versions of x%4, x%8, x%16 etc. Belive it or not, but the version that you show in the description is how gcc handles subregs... it starts OK, but when register allocator comes into play... Confirmed as RA problem, the same thing happens with "long long" and -m32. -- ubizjak at gmail dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ubizjak at gmail dot com Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Keywords| |ra Last reconfirmed|0000-00-00 00:00:00 |2010-04-30 19:00:41 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43883