<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi Krzysztof,</div><div><br></div><div>Thank you for your great guidance! I saw the key sentence: "... <span style="color:rgb(0,0,0);white-space:pre-wrap">we heavily exploit that" :P</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Looks like the hardest part (of course other parts are also not easy for me!) is scheduler,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I am going to figure out </span><font color="#000000"><span style="white-space:pre-wrap">MachinePipeliner and how it works on Hexagon, and try to</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">figure out how </span></font><span style="color:rgb(0,0,0);white-space:pre-wrap">Hexagon use pre-ra and post-ra, then investigate </span><font color="#000000"><span style="white-space:pre-wrap">DFAPacketizer,</span></font></div><div><font color="#000000"><span style="white-space:pre-wrap">VLIWPacketizerList. Thank you : )</span></font></div><div><br></div><div>CY</div><br><div class="gmail_quote"><div dir="ltr">2018年12月15日(土) 0:13 Krzysztof Parzyszek <<a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Cy,<br>
<br>
The main difference between Hexagon (i.e. VLIW) and most other targets <br>
is obviously the fact that we have instruction bundles. (Btw, AMDGPU is <br>
another target that uses bundles, at least in some cases.)<br>
The short answer to how this is handled in our backend, is that we <br>
create the bundles very late in the code generation, so throughout most <br>
of the optimizations, Hexagon code looks as if it was just a typical <br>
sequence of individual instructions (no different from any other <br>
non-VLIW architecture). For the most part this works quite well, except <br>
for instruction scheduling. LLVM has several schedulers (pipeliner, pre- <br>
and post-ra scheduler), and all of them happen before the bundles are <br>
created. Each of the schedulers allows some form of input from <br>
individual targets and we heavily exploit that. In case of the pre-ra <br>
machine scheduler we have our own implementation of the key scheduler <br>
components that connect with the scheduler framework. The machine <br>
pipeliner was originally written for Hexagon before it became <br>
target-independent, but internally it is aware of bundles to some <br>
degree. The schedulers rely on instruction latencies, so we make sure <br>
that we have properly specified. Also, we take advantage of DAG <br>
mutations, which is the mechanism that schedulers provide to give <br>
targets the ability to alter the scheduling graph.<br>
Finally we create bundles using the DFA packetizer, which is a finite <br>
state machine that builds instruction packets based on resource usage <br>
associated with each instruction (that information is specified in the <br>
.td files describing each instruction). This happens after register <br>
allocation. The register allocation for Hexagon is the same as for any <br>
other target, we don't do anything special there.<br>
<br>
-Krzysztof<br>
<br>
<br>
On 12/11/2018 4:36 PM, Cy Cheng wrote:<br>
> Hi paulr,<br>
> Thank you for your response :)<br>
> <br>
> Hi Krzysztof,<br>
> This is really helpful! Thank you for your guidance!!<br>
> I would like to trace the Hexagon's llvm implementation.<br>
> I am very interested on how Hexagon implement instruction<br>
> pattern matching, instruction scheduling, and register<br>
> allocation, could you give me some suggestions or reading<br>
> lists to help me understand Hexagon's llvm implementation?<br>
> Thank you :)<br>
> <br>
> CY<br>
> <br>
> 2018年12月11日(火) 4:19 Krzysztof Parzyszek via llvm-dev <br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>>:<br>
> <br>
> In the intermediate language that assembler works on an instruction is<br>
> represented by an MCInst. An MCInst can have other instructions as<br>
> operands, and this is how the Hexagon backend implements bundles.<br>
> <br>
> A top-level MCInst (i.e. the entire bundle) is encoded all at once from<br>
> the point of view of the target-independent mechanisms. Those<br>
> mechanisms<br>
> use target-specific code that each implementation needs to provide, and<br>
> in your code you can handle each bundle as you want.<br>
> <br>
> Check MCCodeEmitter and how different targets implement it.<br>
> <br>
> As for the syntax---the parser needs to be able to determine the bundle<br>
> boundary. (For example Hexagon uses braces {} to enclose each bundle.)<br>
> The way the assembler works is that it constructs an instruction and<br>
> passes it to the associated streamer. The streamer is typically an<br>
> assembly streamer (i.e. printing the instruction assembly), or an<br>
> object<br>
> file streamer (e.g. ELF, etc.)<br>
> <br>
> The answers to all your questions are "yes", or "it's doable", but the<br>
> degree of complexity may vary between different choices.<br>
> <br>
> The major suggestion that I have is to make sure that the syntax is<br>
> unambiguous, specifically when it comes to bundle boundaries. Another<br>
> suggestion is to maintain the "mnemonic op, op, ..." syntax for<br>
> individual instructions (i.e. mnemonic followed by a list of operands).<br>
> Hexagon has its own assembly syntax that doesn't follow that, and it<br>
> makes things a bit more complicated.<br>
> <br>
> -Krzysztof<br>
> <br>
> -- <br>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
> hosted by The Linux Foundation<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<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/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,<br>
hosted by The Linux Foundation<br>
</blockquote></div></div></div></div></div></div></div>