This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 12 Nov 2013 18:14:45 +0100 (CET)
- Subject: Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.
- Authentication-results: sourceware.org; auth=none
- References: <5271F493 dot 4020308 at redhat dot com> <CAFiYyc1JiWcH05crFnO9tMdouw=Z3TDgexpCTOfX4ezMsF-oTw at mail dot gmail dot com> <CAKOQZ8ytOYug0+FFP6kR_yov1N_D6NERT3Y-n6806xp2GqyPkQ at mail dot gmail dot com> <1586972 dot iyObK3nBib at polaris> <52804ACB dot 9010206 at redhat dot com> <52825A74 dot 8070806 at redhat dot com>
- Reply-to: gcc-patches at gcc dot gnu dot org
On Tue, 12 Nov 2013, Jeff Law wrote:
Here's a patch which arranges to leave a null pointer dereferece in the IL.
For a memory load through a null pointer, we just leave the statement as-is
since the LHS is going to be a throw-away SSA_NAME. For a store through a
null pointer, we try to simplify the RHS when it's trivially easy to do so
(when the RHS is an integral type). This allows DCE to sometimes do a better
job if the RHS is something that was computed on the isolated path. This
could be easily extended to floating types, vectors and structures if someone
is interested. We issue the builtin_trap after the null dereference.
You didn't like Jakub's comment about __builtin_unreachable?
- /* Now delete all remaining statements in this block. */
+ If the dereference is a load, then there's nothing to do as the
+ LHS will be a throw-away SSA_NAME and the LHS is the NULL dereference.
I assume the second LHS should be RHS. Don't you want to mark it somehow
so the next DCE doesn't remove it?
For PR59083, signals as yet another control flow mechanism are a pain...