[llvm-dev] Schedules, latency and register liveness for complex instructions

[via llvm-dev]

This sounds like ReadAdvance (grep the codebase); we use this to model a few instructions that fetch instructions earlier than would otherwise be necessary (or later!).

—escha

> On Dec 1, 2017, at 6:15 AM, ORiordan, Martin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> The CPU that I am targeting is VLIW with no hardware interlocking (the next instruction does not wait for the previous to complete).  This leads to fairly complex scheduling, but can be generally accommodated well in LLVM.
>  
> However, I have a small number of useful instructions with quite complex scheduling interactions between latency, register liveness and which have more than one register as input and more than one as output.
>  
> LLVM assumes that input registers are read as an instruction commences and become dead at that time; while output registers are committed when the instruction latency is complete and they become live at that time.
>  
> But for some instructions this is not the case.  I have one particular example of an instruction where one of the input registers is read and becomes dead as the instruction starts, but the other input register is read and becomes dead at the commencement of the following cycle.  It also writes-back one of the output registers at the end of the 2nd cycle which is when that register becomes truly live, and the other output register is written-back 4 cycles later which is when it becomes live.
>  
> The TableGen descriptions do not seem to have any means of binding a register-liveness schedule to specific operands.
>  
> So far I have omitted supporting these particular instructions as I can’t figure out how they can be modelled within LLVM.  Does anybody know how I might approach describing these kind of semantics to LLVM so that I can safely schedule them?
>  
> Variations of this involve instructions designed for pipelined execution, and in pipelined mode then schedule for some operands is different than for single-issue execution.
>  
> Thanks,
>  
>             MartinO
>  
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> 
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
> 
> 
> _______________________________________________
> 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/20171204/f2b1b201/attachment.html>