3 ms·
You can't remove A (redundant given B) and then subsequently remove B (redundant) as well. As soon as your first pass decides to rely on the presence of the de
by k1t 6y ago
You can't remove A (redundant given B) and then subsequently remove B (redundant) as well.
As soon as your first pass decides to rely on the presence of the dereference as a reason for removing the null check, the dereference needs to be flagged as critical, such that it cannot be removed by a subsequent pass.
Better still, if the compiler does try to remove something that was relied on by an earlier optimization step, alert the user that something is probably wrong with the code.
- MereInterest 6y agoMaybe this is me coming from a C++ background rather than C, but that sounds like a horrible idea. That would mean that any code removed by a branch determination (e.g. if(0) in a macro/template expression) would be assumed to still exist for the further purpose of removing unused variables. Also, this would prevent one of the main benefits of function inlining. Once you have inlined a function, the values of some of the parameters may be known at compile time, resulting in lots of those if(0) parameters. But that is something that was relied on in previous passes, even though it is known to be a static value in the current pass.
- deleted 6y ago[deleted]
- dooglius 6y agoWhy would it mean that? The compiler can still remove anything inside an if(0).