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

[Chuang-Yu Cheng via llvm-dev]

Hi Krzysztof,

Thank you for your great guidance! I saw the key sentence: "... we heavily
exploit that" :P
Looks like the hardest part (of course other parts are also not easy for
me!) is scheduler,
I am going to figure out MachinePipeliner and how it works on Hexagon, and
try to
figure out how Hexagon use pre-ra and post-ra, then investigate
DFAPacketizer,
VLIWPacketizerList. Thank you : )

CY

2018年12月15日(土) 0:13 Krzysztof Parzyszek <kparzysz at codeaurora.org>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181216/9ad0a1ea/attachment.html>