Re: [PATCH] Isolate erroneous paths optimization -- preserve *0.

[Jeff Law <law at redhat dot com>]

On 11/12/13 10:14, Marc Glisse wrote:
> 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?
No, it's certainly not appropriate for this optimization.  The problem 
with using builtin_unreachable is if you do reach that point, you fall 
into an unrelated blob of code in the executable.  That is a huge 
security issue.

> > -  /* 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?
I'll fix the comment.  Good point about DCE possibly removing the code. 
 I'll have to take a look at that.


> For PR59083, signals as yet another control flow mechanism are a pain...
Yup.  The ability to catch the null dereference in a signal handler is 
the primary motivation behind keeping the dereference in the IL.

jeff