From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4455 invoked by alias); 4 Jul 2013 10:39:43 -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 4357 invoked by uid 48); 4 Jul 2013 10:39:31 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended Date: Thu, 04 Jul 2013 10:39: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.3.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub 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: cc attachments.created 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: 2013-07/txt/msg00247.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 30453 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30453&action=edit gcc49-pr29776.patch Untested VRP patch. There is SSA_NAME_RANGE_INFO support being reviewed currently which will make VRP info persistent and some zero/sign-extension pass that makes use of that info, perhaps that will take care of the rest. I'm not 100% sure about CLZ/CTZ in the patch, because it could return any value for argument of 0, but as we document it as undefined behavior, perhaps it is fine. With more code we could do even better than this and define from argument's VR smaller VR_RANGE than this patch does, say for ffs if 0 isn't in the VR_RANGE of the argument, the minimum value of the builtin won't be 0, but 1, and from maximum value we could take floor_log of the maximum value plus 1 as the maximum of the resulting range. Ditto for popcount, for parity the current [0, 1] is sufficient, for clz we could use precision minus floor_log of the maximum value as the minimum of resulting vr, for ctz derive from it maximum. Dunno if it is worth it though.