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

Cy Cheng via llvm-dev llvm-dev at lists.llvm.org
Tue Dec 11 14:36:58 PST 2018

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 :)


2018年12月11日(火) 4:19 Krzysztof Parzyszek via llvm-dev <
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
> 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/20181212/2d4587f2/attachment.html>

More information about the llvm-dev mailing list