Re: Optimization techniques

On 2019-05-02, Martin Ward <martin@gkc.org.uk> wrote:
> On 26/04/19 19:46, Martin Ward wrote:
>> Note that even knowing that there is undefined behaviour, you still
>> may not be able to avoid it by testing for its occurrence: the
>> optimiser might spot that you are testing for undefined behaviour and
>> optimise away your test, because it is allowed to assume that the
>> undefined behaviour can never happen! (This is what actually occurred
>> in the last example I gave).
>
> I was a little hasty here. As I now understand it, the real problem
> with the example was that undefined behaviour occured before
> it was tested for, and this resulted in the test being optimised away:
>
> struct agnx_priv *priv = dev->priv;
> if (!dev) return;
> ... do stuff using dev ...


Here, clearly, the compiler is acting on knowledge that is supicious,
without sharing it in the form of a diagnostic.


The compiler knows that the pointer is used first, and then tested
for null afterward, because that's the logical basis for removing the
test. The pointer being used is what it's taking as the assurance that
it isn't null, which is the basis for deleting the null test.


But if a pointer is used first, and tested for null afterward, that
is, first and foremost, a code smell which deserves a diagnostic.


Tests of run-time conditions should not be carelessly deleted without a
diagnostic. Especially tests that speak to the grave validity of a datum
such as a pointer.

Return to the comp.compilers page.
Search the comp.compilers archives again.