[llvm-dev] Implement VLIW Backend on LLVM (Assembler Related Questions)

[Krzysztof Parzyszek via llvm-dev]

Hi Cy,

The main difference between Hexagon (i.e. VLIW) and most other targets 
is obviously the fact that we have instruction bundles. (Btw, AMDGPU is 
another target that uses bundles, at least in some cases.)
The short answer to how this is handled in our backend, is that we 
create the bundles very late in the code generation, so throughout most 
of the optimizations, Hexagon code looks as if it was just a typical 
sequence of individual instructions (no different from any other 
non-VLIW architecture). For the most part this works quite well, except 
for instruction scheduling. LLVM has several schedulers (pipeliner, pre- 
and post-ra scheduler), and all of them happen before the bundles are 
created. Each of the schedulers allows some form of input from 
individual targets and we heavily exploit that. In case of the pre-ra 
machine scheduler we have our own implementation of the key scheduler 
components that connect with the scheduler framework. The machine 
pipeliner was originally written for Hexagon before it became 
target-independent, but internally it is aware of bundles to some 
degree. The schedulers rely on instruction latencies, so we make sure 
that we have properly specified. Also, we take advantage of DAG 
mutations, which is the mechanism that schedulers provide to give 
targets the ability to alter the scheduling graph.
Finally we create bundles using the DFA packetizer, which is a finite 
state machine that builds instruction packets based on resource usage 
associated with each instruction (that information is specified in the 
.td files describing each instruction). This happens after register 
allocation. The register allocation for Hexagon is the same as for any 
other target, we don't do anything special there.

-Krzysztof


On 12/11/2018 4:36 PM, Cy Cheng wrote:
> Hi paulr,
> Thank you for your response :)
> 
> Hi Krzysztof,
> This is really helpful! Thank you for your guidance!!
> I would like to trace the Hexagon's llvm implementation.
> I am very interested on how Hexagon implement instruction
> pattern matching, instruction scheduling, and register
> allocation, could you give me some suggestions or reading
> lists to help me understand Hexagon's llvm implementation?
> Thank you :)
> 
> CY
> 
> 2018年12月11日(火) 4:19 Krzysztof Parzyszek via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>:
> 
>     In the intermediate language that assembler works on an instruction is
>     represented by an MCInst. An MCInst can have other instructions as
>     operands, and this is how the Hexagon backend implements bundles.
> 
>     A top-level MCInst (i.e. the entire bundle) is encoded all at once from
>     the point of view of the target-independent mechanisms. Those
>     mechanisms
>     use target-specific code that each implementation needs to provide, and
>     in your code you can handle each bundle as you want.
> 
>     Check MCCodeEmitter and how different targets implement it.
> 
>     As for the syntax---the parser needs to be able to determine the bundle
>     boundary. (For example Hexagon uses braces {} to enclose each bundle.)
>     The way the assembler works is that it constructs an instruction and
>     passes it to the associated streamer. The streamer is typically an
>     assembly streamer (i.e. printing the instruction assembly), or an
>     object
>     file streamer (e.g. ELF, etc.)
> 
>     The answers to all your questions are "yes", or "it's doable", but the
>     degree of complexity may vary between different choices.
> 
>     The major suggestion that I have is to make sure that the syntax is
>     unambiguous, specifically when it comes to bundle boundaries. Another
>     suggestion is to maintain the "mnemonic op, op, ..." syntax for
>     individual instructions (i.e. mnemonic followed by a list of operands).
>     Hexagon has its own assembly syntax that doesn't follow that, and it
>     makes things a bit more complicated.
> 
>     -Krzysztof
> 
>     -- 
>     Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>     hosted by The Linux Foundation
>     _______________________________________________
>     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
> 


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation