<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">CC'ed the list.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I agreed. Since Rick tends to compute latency for cortex-m0, I think the result is okay?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-11 4:22 GMT+08:00 UE US <span dir="ltr"><<a href="mailto:uexplorer666@gmail.com" target="_blank">uexplorer666@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>The related functions compute scheduling hazards at the DAG level and use it for optimization purposes. They can provide info ALUs which have a defined latency, but otherwise guess both MachineInstructions and TargetInstructions to be one cycle, which isn't true for most processors or instructions these days. You'd likely get reasonable results out of MIPS or ARM with it, but I don't think x86 models all of the instructions well enough to be accurate. It's mainly for schduling ALU instructions alongside AVX and AGU and making sure their counts (execution + op) match up in a way that will allow simultaneous execution on the same core and prefetch as close to optimal as possible, as I understand things. Splitting a basic block naively might cause various extra cycles to occur, and according to Intel the instruction reordering hardware isn't free either. With prefetches, branch prediction, reordering, and speculative execution there are too many factors to do more than best predict what will run best on the machine knowing those cycles, but they're more of a guideline. <br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="m_9031783388302888783gmail_signature" data-smartmail="gmail_signature">GNOMETOYS<br></div></div><div><div class="h5">
<br><div class="gmail_quote">On Fri, Nov 10, 2017 at 8:22 AM, 陳韋任 via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I believe so, though I am not expert in this field. :)</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_9031783388302888783h5">2017-11-09 20:41 GMT+08:00 Rick Veens via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_9031783388302888783h5"><div dir="ltr">Hi all,<div><br></div><div>I'm interested in obtaining the cycles spend by the CPU from LLVM and i was wondering if this was possible to obtain this with the scheduling information from LLVM. (For the cortex-m0 in particular).</div><div><br></div><div>I found the following function : <span style="font-size:12.8px">getInstrLatency() in the </span><span style="font-size:12.8px">TargetInstrInfo class.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">If i sum the latencies of the instructions in a basic block i suppose i will get the total cycle cost for the cortex-m0.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">From what i understand is that there are multiple ways of doing scheduling in LLVM. </span></div><div><span style="font-size:12.8px">I have read about one way which is using Itenaries and another which is using SchedMachineModel.</span></div><div><br></div><div>Will the above function always give me the latencies, independent on the scheduling method used ?</div><div><br></div><div>Sorry if this is a stupid question, i'm a beginner to LLVM.</div><div><br></div><div>Best regards,</div><div><br></div><div>Rick Veens</div></div>
<br></div></div>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><span class="m_9031783388302888783HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_9031783388302888783m_-4487025281217691644gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Wei-Ren Chen (陳韋任)<br>Homepage: <a href="https://people.cs.nctu.edu.tw/~chenwj" target="_blank">https://people.cs.nctu.edu.tw/<wbr>~chenwj</a></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Wei-Ren Chen (陳韋任)<br>Homepage: <a href="https://people.cs.nctu.edu.tw/~chenwj" target="_blank">https://people.cs.nctu.edu.tw/~chenwj</a></div></div></div>
</div>