[bug #58427] Cost-base optimiser breaks short-circuit evaluation

[James Youngman]

Follow-up Comment #3, bug #58427 (project findutils):

I agree with disabling arm-awapping for -O0.

I agree that we should fix the inconsistency between documentation and
implementation regarding the default optimization level.

I agree that arm-swapping E1 -a E2, or arm-awapping E1 -o E2 for any case
where the order of evaluation is user-visible is a bug.   Specifically, the
only way the user should be able to determine that the execution order has
been modified is by using the -D option to ask find what the executed version
of the expression is.

As a corollary, it should not be necessary for the user to specify
POSIXLY_CORRECT in order to inhibit arm-awapping and thus get correct
behaviour.   The user should also, for what it's worth, get correct behaviour
for -On for any integer value of n.

Since we currently have a bug, I am OK with any of the obvious approaches to
fixing this in the short term (e.g. defaulting to a lower -O value, entirely
disabling arm-awapping for now, etc.)

Properly detecting interactions between EXPR1 and EXPR2 seems to be the
desirable way to go in the longer term, but for now if we can't do that we may
need to disable some features in order to restore correct behaviour.   Perhaps
that could be a short-term solution.

While I don't object to adding a configure option to set the default
optimisation level, I also don't think it's fair to "export" responsibility
for mitigating this problem to packagers.

On the Cost-Based Optimizer more generally, I don't think there have been any
systematic measurements of its effectiveness.   It is not impossible that
performance benefits arising from it may turn out to be either too small to
measure or too small to justify the ongoing maintenance burden that the code
imposes.   I wrote the code but I'm not sentimental about it.  If the benefit
obtained by keeping it is less then the cost of doing so, we should probably
remove it.

Lastly on the spelling aspect, the origin of the problem arises in differences
between UK English (of which I am a speaker) and US English.  US English
standardised on -ize endings for a lot of words where correct UK English is
-ise.   However, the word "atomize" is not one of those words.  In UK English
"atomize" is correct.   But because many people are aware of the -ize/-ise
differences, there is a popular assumption among UK English speakers that the
-ise form should be used there there is an -ize ending in US English.   That's
not always the case, but it has led to "atomise" becoming an accepted UK
English alternative form of the correct UK English word "atomize".    The same
is true of the word "optimize".  I'm to blame for the introduction of
"optimise" into the findutils documentation.  Sorry.  All uses of "optimise"
should be changed to "optimize".


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58427>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/