[llvm-dev] About CodeGen quality

mats petersson via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 14 09:10:19 PDT 2017


Would probably help if you explained which backend you are working on
(assuming it's a publicly available one). An example, with source that can
be compiled by "anyone", along with the generated "bad code" and what you
expect to see as "good code" would also help a lot.

>From the things I've seen, it's not noticeably worse (or better) than other
compilers. But it's not an area that I've spent a LOT of time on, and the
combination of generic LLVM operations and the target implementation will
determine the outcome - there are lots of clever tricks one can do at the
machine-code level, that LLVM can't "know" in generic ways, since it's
dependent on specific instructions. Most of my experience comes from x86
and ARM, both of which are fairly well established architectures with a
good amount of people supporting the code-gen part. If you are using a
different target, there may be missing target optimisations that the
compiler could do.

I probably can't really help, just trying to help you make the question as
clear as possible, so that those who may be able to help have enough
information to work on.

--
Mats

On 14 June 2017 at 13:57, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote:

> Hi All,
>
>   Is there known issue that LLVM is bad at codegen for some language
> structure, say C bitfield?
> Our custom backend generates inefficient code for bitfield access, so I am
> wondering where
> should I look into first.
>
>   Thanks.
>
> Regards,
> chenwj
>
> --
> Wei-Ren Chen (陳韋任)
> Homepage: https://people.cs.nctu.edu.tw/~chenwj
>
> _______________________________________________
> 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/20170614/001b7f50/attachment.html>


More information about the llvm-dev mailing list