From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14152 invoked by alias); 24 Oct 2013 12:03:22 -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 14094 invoked by uid 48); 24 Oct 2013 12:03:19 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/58359] __builtin_unreachable prevents vectorization Date: Thu, 24 Oct 2013 12:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: missed-optimization 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: 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-10/txt/msg01749.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 --- Comment #11 from Marc Glisse --- (In reply to Jakub Jelinek from comment #10) > That is still wrong, __builtin_unreachable is still very much useful even at > the RTL level (where we expand it as basic blocks without successors). > Perhaps if-conversion (for LOOP_VERSIONED loop only) can just drop the > __builtin_unreachable () from the to be vectorized loop? It isn't just vectorization, or even just loop optimizations that are hindered by spurious control flow. Most of the __builtin_unreachable I see are of the form: if(x<0)__builtin_unreachable(); (often hidden below a macro called ASSUME or a similar name) For those, it is tempting to say that replacing the GIMPLE_COND, leading to a block that contains only a call to __builtin_unreachable, with an ASSERT_EXPR, or range information on this SSA_NAME (now that we store it), or anything without control flow, wouldn't lose any information. In reality, it would still lose it sometimes, but I don't know how often/bad that is. Just thinking of lowering *some* of the calls earlier... (though it wouldn't help with comment #2, where tree-tailcall.c should probably be taught about __builtin_unreachable)