You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, notice that the two stack arrays have been csetboundsed twice, once before the local zeroing loop and once in the use as arguments, even in -Oz. This has caused a bloat of 20% in code size in certain embedded applications.
When optimising for code size, it would break even with csetbounds on each alloca even if it's used only twice, by storing it (either in a callee-saved register or a stack slot) and loading it back (either a cmove or a clcsp). If the same alloca is used more than twice, then storing and loading definitely wins.
I suspect it has something to do with local and external allocas on different paths, because two external calls on foo() and bar() correctly use callee-saved regs. I would appreciate it if there could be some pointers on a local workaround for this, in case this is non-trivial to fix upstream.
The text was updated successfully, but these errors were encountered:
The function in the code snippet of
https://cheri-compiler-explorer.cl.cam.ac.uk/z/4srf41
creates two allocas which are bounded before being accessed locally or used as arguments to external functions.
However, notice that the two stack arrays have been
csetbounds
ed twice, once before the local zeroing loop and once in the use as arguments, even in-Oz
. This has caused a bloat of 20% in code size in certain embedded applications.When optimising for code size, it would break even with
csetbounds
on each alloca even if it's used only twice, by storing it (either in a callee-saved register or a stack slot) and loading it back (either acmove
or aclcsp
). If the same alloca is used more than twice, then storing and loading definitely wins.I suspect it has something to do with local and external allocas on different paths, because two external calls on
foo()
andbar()
correctly use callee-saved regs. I would appreciate it if there could be some pointers on a local workaround for this, in case this is non-trivial to fix upstream.The text was updated successfully, but these errors were encountered: