On 2023-05-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/10/2023 9:23 AM, Johnny Billquist wrote:
>> On 2023-05-10 14:23, Simon Clubley wrote:
>>> There's no way that x86-64 VMS, at this point in its lifecycle, can
>>> meet those criteria, although hopefully that will change rapidly in
>>> the not too distant future.
>>>
>>> For one thing, x86-64 VMS is still built using non-optimised compilers.
>>>
>>> Any person with any experience elsewhere of the implications of that,
>>> should be asking how many bugs and other issues will emerge once VMS is
>>> built using optimised compilers ?
>>
>> This is utter nonsense. Optimizing code don't suddenly create new bugs.
>> Unless there are bugs in the toolchain, non-optimized code and optimized
>> code will produce the same results, but the amount of time and memory
>> required might differ. Or else the bugs are already there in the
>> unoptimized code.
>
> Correct code will produce the same result non-optimized and optimized.
>

Unless the optimiser has a bug in it. :-)

> In-correct code can produce different results.
>

Yes. _Apparently_ working code can suddenly become non-working code when
an optimiser is turned on for the first time or (as you point out in
another reply) when the optimiser is changed.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/10/2023 1:37 PM, Simon Clubley wrote:
> On 2023-05-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/10/2023 9:23 AM, Johnny Billquist wrote:
>>> On 2023-05-10 14:23, Simon Clubley wrote:
>>>> There's no way that x86-64 VMS, at this point in its lifecycle, can
>>>> meet those criteria, although hopefully that will change rapidly in
>>>> the not too distant future.
>>>>
>>>> For one thing, x86-64 VMS is still built using non-optimised compilers.
>>>>
>>>> Any person with any experience elsewhere of the implications of that,
>>>> should be asking how many bugs and other issues will emerge once VMS is
>>>> built using optimised compilers ?
>>>
>>> This is utter nonsense. Optimizing code don't suddenly create new bugs.
>>> Unless there are bugs in the toolchain, non-optimized code and optimized
>>> code will produce the same results, but the amount of time and memory
>>> required might differ. Or else the bugs are already there in the
>>> unoptimized code.
>>
>> Correct code will produce the same result non-optimized and optimized.
>
> Unless the optimiser has a bug in it. :-)

Johnny's premise was "Unless there are bugs in the toolchain".

Per my understanding the optimization happen in generic LLVM code
aka well tested code so the risk of an optimizer bug should be small.

>> In-correct code can produce different results.
>
> Yes. _Apparently_ working code can suddenly become non-working code when
> an optimiser is turned on for the first time or (as you point out in
> another reply) when the optimiser is changed.

It can happen.

Arne

99% of the code is platform-independent and has been compiled and tested with
optimizing compilers on Alpha and Itanium for years. Yes, there is a possibility that
LLVM might have an x86-unique optimization that would expose a latent bug. That can
happen each time we pick up a newer LLVM or even fix a bug. That's why we test.

But back to "what is a production-ready operating system"? You want all the interfaces
to work correctly. A "production-ready platform" would also include available and tested
layered products and compilers. Building the operating system and those LPs with
optimizing compilers is purely a performance issue.