[llvm-dev] How to implement MyArchInstrInfo::isLoadFromStackSlot where most instructions have an Offset.

Tue Sep 5 11:31:20 PDT 2017

> On Sep 4, 2017, at 3:07 AM, Dominique Torette via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
>  
> In order to handle register allocation of more complex functions, I have to implement the others methods from the MyArchInstrInfo.cpp.
> The first one is the isLoadFromStack, that return the frameIndex referenced by the Machine Instruction.
> I took a look at the implementation of this function in many others architectures. It’s always a switch/case on a few instructions of the architecture, followed by some access to the properties of the instruction parameters.
> With my architecture, most of the selected instruction (MOV but also arithmetic instructions) will load one or even worst two operands from a Stack Slot: the Offset and Offset/Offset addressing mode.
>  
> /// isLoadFromStackSlot - If the specified machine instruction is a direct
> /// load from a stack slot, return the virtual or physical register number of
> /// the destination along with the FrameIndex of the loaded stack slot.  If
> /// not, return 0.  This predicate must return 0 if the instruction has
> /// any side effects other than loading from the stack slot.
> unsigned CLPInstrInfo::isLoadFromStackSlot(const MachineInstr *MI,
>                         int &FrameIndex) const {
>  
> What is the purpose this method? Finding the highest position already allocated in the Stack?
This callback doesn't seem to be used too much. In general it is a good idea to look for the users of a callback to get a feeling for how much/where it is used.
This one in particular seems rarely used:
- Some code uses it to identify "reload" instructions to create statistics and comments in the assembly output. (This doesn't seem to be perfect as for example I don't see it catching the cases where the reload was folded into arithmetic instruction on x86).
- StackSlotColoring uses it to remove some store/load sequences if easily possible.
- InlineSpiller/MachineLICM appear to have some rules to enable some optimisations for reloads (identifying certain safe code patterns).

So this all seems to only be involved in pretty minor optimizations. The code in MachineLICM looks to me like it assumes only one FrameIndex is touched, so you may be better off not reporting anything if you have two loads folded in a single instruction. (Short of improving/fixing the usage there).

- Matthias

> In that case, for Offset/Offset addressing mode, I will have to return the highest offset.
> As for other architecture, I can implement a switch/case, but it will be very large. Most of the instructions have an Offset/Offset addressing mode.
> Do I have to implement this methods only for the MOV instructions or also for the arithmetic instructions fetching operands from Stack?
> Is there a way to add a property to tag ‘LoadFromStackSlot’ instructions or instruction classes at the level of MyArchInstrInfo.td or MyArchInstrDef.td file?
> Any suggestions suggestion are welcome…
>  
> TIA,        Dominique Torette
>  
> 
> 
> 
> 
> 
> 
> 
> 
> Dominique Torette 
> System Architect
> Rue des Chasseurs Ardennais - Liège Science Park - B-4031 Angleur 
> Tel: +32 (0) 4 361 81 11 - Fax: +32 (0) 4 361 81 20 
> www.spacebel.be <http://www.spacebel.be/>
>  
> 
> ------------------------------------------------------------------------------
> 
> E-MAIL DISCLAIMER
> 
> The present message may contain confidential and/or legally privileged information. If you are not the intended addressee and in case of a transmission error, please notify the sender immediately and destroy this E-mail. Disclosure, reproduction or distribution of this document and its possible attachments is strictly forbidden.
> 
> SPACEBEL denies all liability for incomplete, improper, inaccurate, intercepted, (partly) destroyed, lost and/or belated transmission of the current information given that unencrypted electronic transmission cannot currently be guaranteed to be secure or error free.
> Upon request or in conformity with formal, contractual agreements, an originally signed hard copy will be sent to you to confirm the information contained in this E-mail.
> 
> SPACEBEL denies all liability where E-mail is used for private use.
> 
> SPACEBEL cannot be held responsible for possible viruses that might corrupt this message and/or your computer system.
> -------------------------------------------------------------------------------
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170905/bac084ae/attachment.html>