Re: Optimization techniques

Kaz Kylheku <847-115-0292@kylheku.com>
Thu, 2 May 2019 17:51:31 +0000 (UTC)

          From comp.compilers

Related articles
[31 earlier articles]
Re: Optimization techniques genew@telus.net (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques genew@telus.net (Gene Wirchenko) (2019-04-30)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-05-01)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-05-01)
Re: Optimization techniques martin@gkc.org.uk (Martin Ward) (2019-05-02)
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-05-02)
Re: Optimization techniques 847-115-0292@kylheku.com (Kaz Kylheku) (2019-05-02)
Re: Optimization techniques robin51@dodo.com.au (Robin Vowels) (2019-05-07)
Re: Optimization techniques david.brown@hesbynett.no (David Brown) (2019-05-07)
Re: Optimization techniques rockbrentwood@gmail.com (2019-09-26)
| List of all articles for this month |

From: Kaz Kylheku <847-115-0292@kylheku.com>
Newsgroups: comp.compilers
Date: Thu, 2 May 2019 17:51:31 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <910eaf6f-f9ae-9c02-5052-f06474024d96@hesbynett.no> 19-04-027 19-05-005
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="95933"; mail-complaints-to="abuse@iecc.com"
Keywords: optimize, errors
Posted-Date: 02 May 2019 14:17:43 EDT

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.


Post a followup to this message

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