[LLVMdev] IR extension proposal: bitset constants
Peter Collingbourne
peter at pcc.me.uk
Thu Jan 29 14:22:48 PST 2015
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
More information about the llvm-dev
mailing list