Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compilers > #2248

Re: Optimization techniques

From Kaz Kylheku <847-115-0292@kylheku.com>
Newsgroups comp.compilers
Subject Re: Optimization techniques
Date 2019-05-02 17:51 +0000
Organization Aioe.org NNTP Server
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>

Show all headers | 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 | NextPrevious 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