llvm dev - Mar 2017 - [RFC] bitfield access shrinking

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.
>
> 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).
> The main generator of the bitwise manipulation is SROA and if it was 
> the only creator of these intrinsics, it would already make things 
> simpler. We'd also need to teach the combiner about them, but
that's
> still fairly localized.
> On the other hand, they would make the intent of the code explicit. 
> Targets could handle them any way they want, whether it's loading an 
> i128, or an i16 from an adjusted offset.
I wouldn't want just SROA to produce them. If we're going to have them, 
then we should canonicalize toward them. That implies having matching 
logic, so perhaps we're back where we started.

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

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>

On 3/10/2017 2:20 AM, Chandler Carruth wrote:
>
> 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.
Interesting. What usually happens in our cases is that the bitwise 
extraction logic gets combined into code that is hard to generate 
optimal code for. It's usually the shifts and ands from the extraction 
code itself that get rewritten between themselves, but I haven't seen 
many cases where the surrounding arithmetic would be a part of it (I 
meant addition, subtraction, etc, not further bitwise ops). When the 
surrounding code has more bitwise operations on the extracted bitfield, 
the extraction may be completely eliminated (which is something that the 
combiner could do).

I agree that if we tried to aggressively canonicalize towards such 
intrinsics, it would likely create more problems than it would solve.

That said, it was just a loose idea, not something I intend to insist on...

>     > The main generator of the bitwise manipulation is SROA
>
>
> ?? Clang directly generates the bit insert and extract patterns as well?
Sorry, I didn't mean to pick on SROA. ;)


-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation