Heap allocation no longer importing allocation capability

[ziuziakowska]

As an exercise for Sonata, we demonstrate usage of cheriot-audit by changing an array from stack to heap allocated, and showing that this results in an import of a sealed capability to allocate memory. An update to CHERIoT-RTOS has caused this import to not be included anymore in the emitted json, and it seems to be caused by this commit: #460. Is it intentional for some heap allocation calls to be optimised out?

See also: lowRISC/sonata-software#81.

[davidchisnall]

Is it intentional for some heap allocation calls to be optimised out?

Yes, if a heap allocation's entire lifecycle (until free or deallocation) can be statically evaluated, then the allocation should be optimised away. In your example, it appears that you aren't doing anything with the allocation that the compiler can't analyse. It's assigned to, but then the pointer leaks. This means that the compiler can infer that there are no possible loads and the stores are dead. After eliminating the stores, we now have a heap allocation with no uses. The compiler can delete the heap allocation.

I think the actual bug here (@resistor) is that we'll probably do this only because you call the global operator new() and not for heap_allocate in general), because we haven't taught LLVM about our allocation functions. Please don't rely on that, we'll fix it soonish!

If you assign the heap pointer to a global (not a static), that will probably prevent it from being optimised away.

[resistor]

I think the actual bug here (@resistor) is that we'll probably do this only because you call the global operator new() and not for heap_allocate in general), because we haven't taught LLVM about our allocation functions. Please don't rely on that, we'll fix it soonish!

CHERIoT-Platform/llvm-project#309