Hacker News new | ask | show | jobs
by int_19h 542 days ago
Why are LLVM compilers "dangerous in some use-cases", and what are those use-cases?
1 comments

Any Real-Time or mcu system that relies on repeatable code-motion behavior, and clock domain crossing mitigation (a named problem with finite solutions.) Many seem to wrongly conflate this with guaranteed-latency schedulers... However, the danger occurs when a compiler fails to account for concurrent event order dependent machine states that do not explicitly lock (i.e. less efficient un-optimized gcc will reproduce consistent register op ordered in time behavior for the same source-code.)

The llvm abstraction behavior is usually fine in multitasking application spaces, but can cause obscure intermittent failure modes if concurrent register states are externally dependent on the architecture explicitly avoiding contention. I would recommend having a look at zynq DMA kernel module memory mapped to hardware io examples.

It seems rather trivial, Best of luck =3

But if you depend on specific ordering of register operations, isn't this kind of code best hand-written in assembly anyway?
In general, assembly code escape blocks are often used with macros for ease of understanding architecture specific builds.

There are binary optimizers and linkers that can still thrash Assembly objects in unpredictable ways.

Best of luck =3