[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

Tue Aug 22 19:46:17 PDT 2017

On Tue, Aug 22, 2017 at 7:18 PM Xinliang David Li via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> 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.
>

I don't really understand this argument...

I don't think we can realistically chase all performance problems that
users aren't aware of or can't measure. And our users *do* care and seem
very good at benchmarking and noticing problems. =]

I also think it is OK if in rare cases programmers have to adapt their
source code to optimize well. We can and should make this as rare as
reasonable from an engineering tradeoff perspective, but at a certain point
we need to work with programmers to find a way to solve the problem. There
exist coding patterns that Clang and LLVM will never be particularly
effective at optimizing, and that seems OK. We just need to have reasonable
engineering requirements for those cases:

1) They need to be quite rare. So far, this issue has come up fairly
infrequently. Not never, but there are many issues that seem to come up
much more often such as inlining issues.

2) We need an effective way to explain how programmers should write code to
optimize well, and this explanation needs to be as simple as possible.

3) We likely need to give programmers *choices* about which direction their
code gets optimized for. And this is (IMO) the biggest practical issue with
the approach in this change (beyond race detection and other semantic
issues).

I'm suggesting that we teach programmers to choose between a bitfield to
get combining-friendly access to tightly packed data, and integer types of
an appropriate size to get inexpensive and predictable loads and stores.
For sub-byte-width and non-byte-aligned bitfields this is already a
necessary property and so it seems like a consistent and easily explained
and taught model.

While there are times where there is a single "right" answer and we only
have to provide that, I don't think this is one of them. I've seen rare but
serious complaints about *both* failing to combine adjacent bit fields and
failing to narrow to small legal integer types. These seem in fundamental
tension, and I would prefer to establish idiomatic patterns for programmers
to request the behavior then need in their application.

>
> 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
>>
>> _______________________________________________
> 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/20170823/2834e4dc/attachment-0001.html>