Embedded code crashing - binary unexpected size

[ebariaux]

Description

Starting from an swift-embedded-examples project with a bit of code added, all works fine for some constant value.
Changing the value of the constant leads to very different size of the produced binary and crash when running on the board.

Reproduction

I started from the https://github.com/apple/swift-embedded-examples.git stm32-uart-echo example and added that bit of code

    let maxIterations = 5
    let c = Complex(-1.0, 1.0)
    var z = Complex<Double>.zero
    var iterations: UInt8 = 0

    while iterations < maxIterations && z.magnitude < 2.0 {
      z = z * z + c
      iterations += 1
    }

    print(iterations)

There is also some basic support code and dependency on the swift-numerics package, the project is available in test/mandelbrot branch at https://github.com/ebariaux/swift-embedded-examples.git

With the above code all is fine and generated Application.bin is 1992 bytes
Changing the maxIterations constant from 5 to 15 in above code results in Application.bin being 4080 bytes and the program crashing.
In addition, the value of that constant should not matter, as the loop should exits as soon as iterations reaches 3.

Expected behavior

Executing the program on the device should not crash.
In addition, I would expect the binary sizes to be fairly similar.

Environment

Apple Swift version 6.2 (swift-6.2-RELEASE)
Target: arm64-apple-macosx15.0
Build config: +assertions

Embedded hardware used is a STM32F746NG DISCO

Additional information

No response

[ebariaux]

@stephentyrone @al45tair This is the strange behaviour I described to you last week. Thx.

[stephentyrone]

@ebariaux as an experiment, can you try using Complex<Float> instead of Double? The STM32F746NG has hardware support for Float, but I think will use a soft-float library for Double.

[ebariaux]

@stephentyrone Crashes the same way. Binary size with 5 as value is identical (1992), binary size with 15 is now 2152 bytes.

[al45tair]

I wonder whether the problem is that setting the iteration count to 15 triggers vectorisation and the compiler thinks you've got NEON or similar when really you haven't. We could confirm by looking at the disassembled code. If that's the case, maybe adding something like -Xclang -fno-vectorize will stop it doing that?

Have you passed any -m options to the compiler to tell it exactly what architecture you're using? And what triple did you tell it to build for exactly?

[stephentyrone]

It would be plausible, but there are no vector instructions for double-precision on armv7.