This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]