[llvm-dev] About CodeGen quality

陳韋任 via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 15 04:06:49 PDT 2017


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


More information about the llvm-dev mailing list