[llvm-dev] About CodeGen quality

[Hiroshi 7 Inoue via llvm-dev]

For this specific case, modifying source code (or the frontend) to use a
struct instead of
bitfield seems to be an easy way since all sizes of bitfields are 8 bits.
But you cannot?
For general cases, you may want to enhance backend to emit
bitextract/bitset.

-----
Hiroshi Inoue <inouehrs at jp.ibm.com>
IBM Research - Tokyo


"llvm-dev" <llvm-dev-bounces at lists.llvm.org> wrote on 2017/06/15 20:06:49:

> From: 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org>
> To: mats petersson <mats at planetcatfish.com>
> Cc: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
> Date: 2017/06/15 20:07
> Subject: Re: [llvm-dev] About CodeGen quality
> Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>
>
> Hi Mats,
>
>   It's private backend. I will try describing what I am dealing with.
>
>     struct S {
>       unsigned int a : 8;
>       unsigned int b : 8;
>       unsigned int c : 8;
>       unsigned int d : 8;
>
>       unsigned int e;
>     }
>
> We want to read S->b for example. The size of struct S is 64 bits,
> and seems LLVM treats it as i64.
> Below is the IR corresponding to S->b, IIRC.
>
>     %0 = load i64, *i64 ptr, align 4;
>     %1 = %0 lshr 8;
>     %2 = %1 and 255;
>
> Our target doesn't support load i64, so we have following code
> in XXXISelLowering.cpp
>
>     setOperationAction(ISD::LOAD, MVT::i64, Custom);
>
> Transform load i64 to load v2i32 during type legalization. During op
> legalization, load v2i32
> is found unaligned (4 v.s. 8), so stack load/store instructions are
> generated. This is one problem.
>
> Besides of that, our target has bitset/bitextract instructions, we
> want to use them on bitfield
> access, too. But don't know how to do that.
>
> Thanks.
>
> Regards,
> chenwj
>
> 2017-06-15 0:10 GMT+08:00 mats petersson <mats at planetcatfish.com>:
> 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

>
>

>
> --
> 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/20170617/d04b0161/attachment.html>