llvm-mos divmod.cc ported from C++ to C incorrectly

[asiekierka]

static __inlinefunc unsigned udiv(unsigned a, unsigned b)
{

This implementation of udiv (and umod, udivmod) will only work on numbers <= 16 bits. As the pi benchmark utilizes division of long (32 bit) numbers, this will not work correctly and lead to a result error.

Using divmod.cc and family directly from llvm-mos-sdk, as opposed to this patched version, allows the pi benchmark to give the correct result; as verified by compiling pi.c directly with llvm-mos-sdk (after patching _putc and _puts calls).

The same applies to mul.c, and potentially other files, I have not checked them all.

I'm getting similar results with merge-sort completing in reasonable time compiled directly with llvm-mos-sdk's standard library on the atari800 emulator, but failing when compiled through oricCompilerBenchmark's suite, but I haven't been able to track those down yet.

[iss000]

Noted. I'll check asap.

[johnwbyrd]

Poke.

[iss000]

Poke.

Thanks for the reminder :)
Now it's fixed and all tests work.

[johnwbyrd]

Yes, and now all llvm-mos tests, including the ones that were working fine before, now take 3 times the previous amount of time and memory as your previous benchmark. This result is not sane.

[asiekierka]

613f95a#diff-70f4dc41f1a432a0131e9a2230954d6fad0063199aacd7aac423ec1d987d79afR15

LTO was commented out, which LLVM-MOS relies on strongly for its optimization strategies. A lot of the best tricks in the compiler are not possible without whole-program analysis, which is not available if link-time optimization is not being used.

[iss000]

Indeed. With '-flto' some tests fail. It needs more deep analyzes what exactly happens.

[johnwbyrd]

Please reopen this issue, or create another corresponding issue.