[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

[Hal Finkel via llvm-commits]

On 08/09/2017 11:03 PM, Chandler Carruth wrote:
> Hal already answered much of this, just continuing this part of the 
> discussion...
>
> On Wed, Aug 9, 2017 at 8:56 PM Xinliang David Li via llvm-commits 
> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>
>     On Wed, Aug 9, 2017 at 8:37 PM, Hal Finkel <hfinkel at anl.gov
>     <mailto:hfinkel at anl.gov>> wrote:
>
>
>         On 08/09/2017 10:14 PM, Xinliang David Li via llvm-commits wrote:
>>          Can you elaborate here too? If there were missed
>>         optimization that later got fixed, there should be regression
>>         tests for them, right? And what information is missing?
>
>         To make a general statement, if we load (a, i8) and (a+2,
>         i16), for example, and these came from some structure, we've
>         lost the information that the load (a+1, i8) would have been
>         legal (i.e. is known to be deferenceable). This is not
>         specific to bit fields, but the fact that we lose information
>         on the dereferenceable byte ranges around memory access turns
>         into a problem when we later can't legally widen. There may be
>         a better way to keep this information other than producing
>         wide loads (which is an imperfect mechanism, especially the
>         way we do it by restricting to legal integer types),
>
>
> I don't think we have such a restriction? Maybe I'm missing something. 
> When I originally added this logic, it definitely was not restricted 
> to legal integer types.

I believe you're right for bitfields. For general structures, however, 
we certainly load individual fields instead of loading the whole 
structure with some wide integer in order to preserve dereferenceability 
information.

>
>         but at the moment, we don't have anything better.
>
>
>     Ok, as you mentioned, widening looks like a workaround to paper
>     over the weakness in IR to annotate the information.  More
>     importantly, my question is whether this is a just theoretical
>     concern.
>
>
> I really disagree with this being a workaround.
>
> I think it is very fundamentally the correct model -- the semantics 
> are that this is a single, wide memory operation that a narrow data 
> type is extracted from.

That is one option. We do need to preserve this information (maybe we 
can do this with TBAA, or similar, or maybe using some other mechanism 
entirely). However, we do try harder to do this with bitfields than with 
other aggregates. If I have struct { int a, b, c, d; } S; and I load 
S.d, we don't do this by loading a 128-bit integer and then extracting 
some part of it. Should we? Probably not. I suspect having better 
support for aggregate memory access would be a better solution. Or, as 
noted, using metadata or some other secondary mechanism.

Maybe more aggressively preserving this information for bit fields is 
the right answer, empirically. I can believe that's true. The 
more-general problem still exists, however.

>
> I think the thing that is seriously weak is the ability to 
> aggressively narrow these operations, and while I agree that this is 
> important it doesn't actually seem to be common. We have a relatively 
> small number of (admitedly important) cases, but even our existing 
> narrowing seems to be very effective for the vast majority of cases.
>
> I would be very hesitant to give up the information preserved by this 
> lowering and representation when we already have very successfully 
> optimized the majority of it effectively during code generation, and 
> have only just started trying a much more aggressive approach. I 
> suspect that the aggressive approach can be made to work, even though 
> it may be quite challenging.

The thing that appeals to me about the IR-transformation approach is the 
ability to handle "hand coded" bit fields as effectively as 
language-level bit fields. I've certainly seen my share of these, and 
they're definitely important. Moreover, this is true regardless of what 
we think about the underlying optimal model for preserving aggregate 
derefereceability in general.

  -Hal

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170809/ac186529/attachment.html>