Re: Optimization techniques

Path	csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end
From	Kaz Kylheku <847-115-0292@kylheku.com>
Newsgroups	comp.compilers
Subject	Re: Optimization techniques
Date	Thu, 2 May 2019 17:51:31 +0000 (UTC)
Organization	Aioe.org NNTP Server
Lines	31
Sender	news@iecc.com
Approved	comp.compilers@iecc.com
Message-ID	<19-05-012@comp.compilers> (permalink)
References	<72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <910eaf6f-f9ae-9c02-5052-f06474024d96@hesbynett.no> <19-04-027@comp.compilers> <19-05-005@comp.compilers>
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
X-submission-address	compilers@iecc.com
X-moderator-address	compilers-request@iecc.com
X-FAQ-and-archives	http://compilers.iecc.com
Xref	csiph.com comp.compilers:2248

Show key headers only | View raw

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.

Back to comp.compilers | Previous | Next — Previous in thread | Find similar

Thread

Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-04-26 19:46 +0100
  Re: language design and Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 21:06 +0000
  Re: Optimization techniques and consistent results David Brown <david.brown@hesbynett.no> - 2019-04-29 16:31 +0200
  Re: Optimization techniques Martin Ward <martin@gkc.org.uk> - 2019-05-02 10:56 +0100
    Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:51 +0000

csiph-web