[llvm-dev] [RFC] bitfield access shrinking

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 10 00:20:08 PST 2017


On Thu, Mar 9, 2017 at 11:22 AM Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On 03/09/2017 12:57 PM, Krzysztof Parzyszek wrote:
> > On 3/9/2017 12:47 PM, Hal Finkel wrote:
> >>
> >> On 03/09/2017 12:28 PM, Krzysztof Parzyszek via llvm-dev wrote:
> >>> We could add intrinsics to extract/insert a bitfield, which would
> >>> simplify a lot of that bitwise logic.
> >>
> >> But then you need to teach a bunch of places about how to simply them,
> >> fold using bitwise logic and other things that reduce demanded bits into
> >> them, etc. This seems like a difficult tradeoff


It's a bit worse than that from what I've seen.

We have a fair amount of code that looks *like* bitfield accesses but is
done manually. So we would have a serious canonicalization issue as well
needing to canonicalize *toward* these intrinsics. =[


> >
> > Bitfield extraction/insertion generally does not simplify well with
> > surrounding arithmetic.
>
> Maybe. I've seen plenty of places where we've simplified bitfield
> extractions/insertions with other using/generating logic (masks, shifts,
> and the like).
>

We have had *numerous* test cases from benchmarks where combining basic
bitfield math is important. So while in some cases it may not be important,
in a number of cases it is and so I feel like we should design things to
support reasonably comprehensive combining of the bitfield accesses.


>
> > The main generator of the bitwise manipulation is SROA


?? Clang directly generates the bit insert and extract patterns as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170310/d2e4ed86/attachment.html>


More information about the llvm-dev mailing list