bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pointer addition and arrays


From: Marc Nieper-Wißkirchen
Subject: Re: pointer addition and arrays
Date: Sun, 17 Dec 2023 11:16:18 +0100


Am So., 17. Dez. 2023 um 09:50 Uhr schrieb Paul Eggert <eggert@cs.ucla.edu>:
On 2023-12-16 04:42, Marc Nieper-Wißkirchen wrote:
> the problem is if further down in the compiler pipeline, the
> P <= P _expression_ produces some intermediate code that becomes equal to
> code the optimizer should rightfully optimize away

I'm skeptical that such optimizations would be worth the trouble in
practice, because any optimization where P==P does not imply P<=P would
run contrary to common sense and programmer intuition.

The C standard is full of such examples "contrary to common sense", and in related areas (e.g. comparison/overflow of (un)signed integers) optimizers are already using these.
 
In practice,
compiler writers who'd employ such optimizations would likely cause more
trouble than they'd cure, and I wouldn't want to encourage them.

If I'm wrong, and in the future these optimizations become valuable and
break programs like Coreutils, we can revisit the issue then. In the
meantime let's leave these sleeping dogs lie. I have little doubt that
Bruno has missed many of the issues and it'd be a waste of our time to
try to find the rest of them.

We don't have to hunt all these issues, but we should correct those we find.

The C standard has always favoured the freedom of compiler writers for efficiency, so it is definitely not wrong by its own measures.  It may not be the best decision for every application area, but there are other programming languages besides C.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]