[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 20:27:27 PDT 2017

On Tue, Aug 22, 2017 at 7:46 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

>
>
> 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. =]
>
>
Here you assume that there is single hotspot that user can notice easily,
but this is usually not the case. In a very large scale, we have a long
tail of not so hot functions, but similar problems like this can add up.

Besides if the problem is obvious for user to detect, why wasn't this
problem detected in LLVM earlier?   I admit, in this particular case, we
actually relied on the competitive analysis -- that is why I said depending
on users for this is not reliable.

For yearsI have told our users (optimization) not to hack source code/or do
manual performance tuning (for instance, adding always inlining, adding
inline keyword, adding manually inserted prefetchings, manual loop
unrolling/peelings, etc ). Not only does this method does not scale (it
only helps user's own program), but more importantly it may get stale
overtime -- for instance, due to hardware change or shifting of hot spots.
It is not uncommon to see user's manual optimiztion which used to work
later becomes performance 'bug' without being noticed for years.   I am
totally fine with temporary source workaround, but they should not relied
upon longer term.

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

As I said, for rare cases or as a temporary solution, it is fine to use
source workaround, but we should continue to push for compiler based
solution because compiler is for everybody/every app.  If compiler really
sucks at something, it should at least produce warnings about (with
something like performance sanitizer), but that should be used as last
resort.

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

If we can teach programmers how to to make a good choice, why can't we
teach the compiler to do so?  I don't  think it is a good idea to set up a
precedence to give up easily on engineering solutions in compiler.

David

>
>
>>
>> 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/cfe-commits/attachments/20170822/f1f807dd/attachment-0001.html>