This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
- From: "glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 24 Oct 2013 12:03:18 +0000
- Subject: [Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
- Auto-submitted: auto-generated
- References: <bug-58359-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> ---
(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)