Hello All. This is purely from a particular VLIW target back-end perspective. There it is possible to schedule an MI on to one of multiple execution pipes. This leads to a different instruction encoding per the pipe it is bound to, and need to percolate this information down. Would it be advisable to extend and use the "MachineInstr.Flags" field for this purpose? Right now this flag seems to consume 2bits space out of total 8 (uint8_t). Could we extend this field to say 32bit or better yet to 64bits like MCInstrDesc.TSFlags? Any suggestions/ideas welcome. Thanks. Girish. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120103/814ec9e8/attachment.html>
Hello> Would it be advisable to extend and use the "MachineInstr.Flags" field for > this purpose? Right now this flag seems to consume 2bits space out of total > 8 (uint8_t). Could we extend this field to say 32bit or better yet to 64bits > like MCInstrDesc.TSFlags? Any suggestions/ideas welcome.While the use of Flags looks really easy approach I don't think it should be used for this purpose. You might want to check the "MachinInstr bundle" thread for discussion on different approaches for VLIW-like MI representations. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Jan 3, 2012, at 7:18 AM, girish gulawani wrote:> This is purely from a particular VLIW target back-end perspective. There it is possible to schedule an MI on to one of multiple execution pipes. This leads to a different instruction encoding per the pipe it is bound to, and need to percolate this information down. > Would it be advisable to extend and use the "MachineInstr.Flags" field for this purpose?No, the MachineInstr objects need to stay as small as possible. For something like this, I would suggest that you add an immediate operand to the relevant instructions. That gives you 64 bits of flags you can use any way you like. /jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120103/9721b9f6/attachment.html>