https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689
--- Comment #4 from Jeffrey A. Law <law at redhat dot com> ---
So it occurs to me that in this specific case if DSE did a better job we would
eliminate the first conditional branch which in turn would eliminate the need
for jump threading and the const/copy propagation that is causing headaches.
And just to be clear that won't fix the more general case where a conditional
const/copy propagation changes the destination object of checked routine like
memcpy. Even so, improving DSE is generally a good thing.
So with that in mind, this is what the key parts of the IL looks like in DSE1:
;; basic block 2, loop depth 0, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE, VISITED)
;; pred: ENTRY (FALLTHRU,EXECUTABLE)
h$data_33 = l.data;
if (h$data_33 != &__sb_slop)
goto <bb 3>; [70.00%]
else
goto <bb 4>; [30.00%]
;; succ: 3 [70.0% (guessed)] (TRUE_VALUE,EXECUTABLE)
;; 4 [30.0% (guessed)] (FALSE_VALUE,EXECUTABLE)
;; basic block 3, loop depth 0, maybe hot
;; prev block 2, next block 4, flags: (NEW, REACHABLE, VISITED)
;; pred: 2 [70.0% (guessed)] (TRUE_VALUE,EXECUTABLE)
*h$data_33 = 0;
;; succ: 4 [always] (FALLTHRU,EXECUTABLE)
;; basic block 4, loop depth 0, maybe hot
;; prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;; pred: 3 [always] (FALLTHRU,EXECUTABLE)
;; 2 [30.0% (guessed)] (FALSE_VALUE,EXECUTABLE)
_23 = __builtin_object_size (h$data_33, 0);
_25 = __builtin___memcpy_chk (h$data_33, "abcd", 4, _23);
We can see that the store in BB3 will always be overwritten by the memcpy. I'm
actually a bit surprised that DSE didn't catch this and remove the *h$data_33 =
0 statement. [ Imagine a pause here while I throw things under the debugger...
]
Ah, b_o_s is considered as potentially reading h$data_33. If we fix that, then
we end up removing the store as dead and we get exactly the cascading events we
want and the bogus warning is avoided.
For reasons unknown we consider _b_o_s pure, not const. Jakub thinks were just
being very cautious given the security implications around mucking up _b_o_s.
ANyway, I'm going to dig into that history and see if we ever had it or
discussed the constness of _b_o_s.
