[llvm-dev] About CodeGen quality

Thu Jun 15 05:20:53 PDT 2017

I may be out to lunch here but this sounds like something that SROA
converts into an i64 load. I wonder if disabling it produces IR that is
easier for your target to handle.
Of course, this isn't to say that simply disabling SROA is a viable
solution, but it may give you some ideas as to where to go in terms of
looking for a solution.

You also may be able to combine such patterns in the SDAG (before
legalization) into loads that your target can handle.

This is all kind of speculative but hopefully it sheds some light on what
might be going on.

On Thu, Jun 15, 2017 at 1:45 PM mats petersson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
>>
>
> _______________________________________________
> 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/20170615/b237a8bc/attachment.html>