[llvm-dev] Intercepting lowering of stack adjustments

Martin J. O'Riordan via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 31 09:22:19 PST 2017


Thanks. that looks really promising!  I hadn’t spotted that ISD node before.

 

All the best,

 

            MartinO

 

From: fglaser at apple.com [mailto:fglaser at apple.com] On Behalf Of escha at apple.com
Sent: 31 January 2017 15:06
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: LLVM Developers <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Intercepting lowering of stack adjustments

 

 

On Jan 30, 2017, at 6:18 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:

 

For a long time we have had code for custom lowering of adjustments to the stack pointer.  But until recently we did not realise that we were handling only places that provided a fixed-value for such adjustments, and the ISD nodes ‘ADJCALLSTACKDOWN’ and ‘ADJCALLSTACKUP’ are only described in our TableGen descriptions for immediates.  This hasn’t previous mattered as LLVM produces valid instruction sequences for variable adjustments anyway using an intermediate register.

 

However, we have a recent requirement to also perform custom handling of stack adjustments for non-immediate values, for instance those that reserve stack for VLAs and ‘alloca’.  I would like to be able to intercept lowering for these where a computed value is used, and to be able to differentiate between when stack is being reserved and when it is being released.

 

Where should I best handle this?  All of the targets that use the ‘ADJCALLSTACK’ nodes appear to do so only for immediate values, so I haven’t been able to learn by example.

 

If I’m not mistaken, try grepping for DYNALLOC; that should point you to how a number of targets implement allocas.

 

—escha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/9706fe71/attachment.html>


More information about the llvm-dev mailing list