llvm dev - Jan 2015 - [LLVMdev] IR extension proposal: bitset constants

On 29 Jan 2015 11:36, "Sean Silva" <chisophugis at gmail.com>
wrote:
>
>
>
> On Thu, Jan 29, 2015 at 12:53 AM, Renato Golin <renato.golin at
linaro.org>
wrote:
>>
>> So, bitset would be a property that means : globals with the same name
will append on a string of bits in the order in which they appear, and it's
the job of the front end to make sure the correct order is followed in
every unit, so that linking does the right job in every corner
case?
>>
>> Could that be used for efficient global boolean flags, like LLVM's
options? Even if you don't need the range check, you get the bit mask check
for free.
>
> Maybe during LTO... in general they would need to have distinct addresses.
>
> Actually, Peter, would it be possible to prototype this with an appending
i8 array that we already have in the IR? Some space overhead compared to
appending bits, but could allow for a quick prototype.

This would work, and you could make the packaging during your lowering
pass, no?

Cheers,
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150129/f77055d6/attachment.html>

On Thu, Jan 29, 2015 at 12:16:58PM +0000, Renato Golin
wrote:
> On 29 Jan 2015 11:36, "Sean Silva" <chisophugis at
gmail.com> wrote:
> >
> >
> >
> > On Thu, Jan 29, 2015 at 12:53 AM, Renato Golin <renato.golin at
linaro.org>
> wrote:
> >>
> >> So, bitset would be a property that means : globals with the same
name
> will append on a string of bits in the order in which they appear, and
it's
> the job of the front end to make sure the correct order is followed in
> every unit, so that linking does the right job in every corner case?
> >>
> >> Could that be used for efficient global boolean flags, like
LLVM's
> options? Even if you don't need the range check, you get the bit mask
check
> for free.
> >
> > Maybe during LTO... in general they would need to have distinct
addresses.
> >
> > Actually, Peter, would it be possible to prototype this with an
appending
> i8 array that we already have in the IR? Some space overhead compared to
> appending bits, but could allow for a quick prototype.
> 
> This would work, and you could make the packaging during your lowering
> pass, no?
I don't think it could be made to work in all cases. Consider this class
hierarchy, with each class defined in a separate translation unit:

class A { virtual void f(); };
class B { virtual void g(); };
class C { virtual void h(); };
class D : A, B { virtual void f(), g(); };
class E : B, C { virtual void g(), h(); };

vtables:

A = { &A::rtti, &A::f };
B = { &B::rtti, &B::g };
C = { &C::rtti, &C::h };
D = { &D::rtti, &D::f, &D::rtti, &D::g };
E = { &E::rtti, &E::g, &E::rtti, &E::h };

bitsets (assuming layout A,B,C,D,E):

A = { 0,1,0,0,0,0,0,1,0,0,0,0,0,0 }
B = { 0,0,0,1,0,0,0,0,0,1,0,1,0,0 }
C = { 0,0,0,0,0,1,0,0,0,0,0,1,0,1 }
D = { 0,0,0,0,0,0,0,1,0,0,0,0,0,0 }
E = { 0,0,0,0,0,0,0,0,0,0,0,1,0,0 }

Note that because of the existence of class C, we must leave a gap in
the bitset for A between A and D. Because none of the translation units
in C's hierarchy are necessarily aware of A, they cannot know to leave a
gap. Attempting to fix this in the bitset lowering pass would just introduce
more complexity, IMO.

So I don't think it is possible (or simple, at the least) without references
to other globals in the thing we use to build the bitset.

I've been working on a patch that implements the bitset attribute and bitset
lowering pass. I'll see if I can send it out later today.

Thanks,
-- 
Peter

On Thu, Jan 29, 2015 at 02:22:48PM -0800, Peter Collingbourne
wrote:
> I've been working on a patch that implements the bitset attribute and
bitset
> lowering pass. I'll see if I can send it out later today.
http://reviews.llvm.org/D7288

Thanks,
-- 
Peter