[PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Xinliang David Li via llvm-commits]

On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> chandlerc added a comment.
>>>
>>> I'm really not a fan of the degree of complexity and subtlety that this
>>> introduces into the frontend, all to allow particular backend optimizations.
>>>
>>> I feel like this is Clang working around a fundamental deficiency in
>>> LLVM and we should instead find a way to fix this in LLVM itself.
>>>
>>> As has been pointed out before, user code can synthesize large integers
>>> that small bit sequences are extracted from, and Clang and LLVM should
>>> handle those just as well as actual bitfields.
>>>
>>> Can we see how far we can push the LLVM side before we add complexity to
>>> Clang here? I understand that there remain challenges to LLVM's stuff, but
>>> I don't think those challenges make *all* of the LLVM improvements off the
>>> table, I don't think we've exhausted all ways of improving the LLVM changes
>>> being proposed, and I think we should still land all of those and
>>> re-evaluate how important these issues are when all of that is in place.
>>>
>>
>> The main challenge of doing  this in LLVM is that inter-procedural
>> analysis (and possibly cross module) is needed (for store forwarding
>> issues).
>>
>> Wei, perhaps you can provide concrete test case to illustrate the issue
>> so that reviewers have a good understanding.
>>
>
> It doesn't seem like all options for addressing that have been exhausted.
> And even then, I feel like trying to fix this with non-obvious (to the
> programmer) frontend heuristics isn't a good solution. I actually *prefer*
> the source work around of "don't use a bitfield if you *must* have narrow
> width access across modules where the optimizer cannot see enough to narrow
> them and you happen to know that there is a legal narrow access that
> works". Because that way the programmer has *control* over this rather than
> being at the whim of whichever side of the heuristic they end up on.
>


The source workaround solution *does not* scale. Most importantly, user may
not even be aware of the problem (and performance loss) unless  compiling
the code with another compiler and notice the performance difference.

David

>
>
>>
>> David
>>
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D36562
>>>
>>>
>>>
>>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170822/8bbd4d60/attachment.html>