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

[Jeff Law]

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