[llvm-dev] About CodeGen quality

mats petersson via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 15 04:44:42 PDT 2017


I understand the problem. Can't offer any useful help - most likely, you
need to add some code to help the instruction selection or some such... but
it's not an area that I'm familiar with...

--
Mats

On 15 June 2017 at 12:06, 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote:

> 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/77fec40d/attachment.html>


More information about the llvm-dev mailing list