llvm dev - Oct 2015 - Handling of non-fixed stack reservations

Recently I was examining a code generation bug in our backend, but while I
was examining the code generated I noticed a pattern of calls to functions
which in each case reserved an extra 20 bytes on the stack, performed the
call, and then unreserved the 20 bytes.  It then did the same for the next
call, and the next, and so on for several calls in a row.

The 20-bytes is just a property of this particular code, it could be any
value, but is there an option or interface to override somewhere in the
target machine description that allows the target to specify a threshold for
variable stack reservations so that values under a given threshold are put
in the fixed stack reservation?  Or perhaps a pass that I don't yet know of
that can observe such patterns and perform the and aggregated reservation of
the largest amount just once before the sequence of calls, and then restore
after they have completed?

The code generated isn't wrong, it's just not as optimal as I'd
like.

Thanks,

	MartinO

On 3 October 2015 at 18:28, Martin J. O'Riordan via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The 20-bytes is just a property of this particular code, it could be any
> value, but is there an option or interface to override somewhere in the
> target machine description that allows the target to specify a threshold
for
> variable stack reservations so that values under a given threshold are put
> in the fixed stack reservation?  Or perhaps a pass that I don't yet
know of
> that can observe such patterns and perform the and aggregated reservation
of
> the largest amount just once before the sequence of calls, and then restore
> after they have completed?
I don't think there's any heuristic-based tuning available (most
targets just allocate enough stack for all possible calls on function
entry whenever they can, I believe). But the toggle you can play with
is the hasReservedCallFrame callback.

Cheers.

Tim.