Dominique Torette via llvm-dev
2017-Sep-04 10:07 UTC
[llvm-dev] How to implement MyArchInstrInfo::isLoadFromStackSlot where most instructions have an Offset.
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?
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
[http://www.spacebel.be/wp-content/uploads/2011/06/image-sign-sbp.jpg]
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.
-------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170904/5dad1dc4/attachment.html>
Matthias Braun via llvm-dev
2017-Sep-05 18:31 UTC
[llvm-dev] How to implement MyArchInstrInfo::isLoadFromStackSlot where most instructions have an Offset.
> 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>