search for: bitset

...1,0,1,0,0,1,0} B = {0,0,0,1,0,0,0,0} C = {0,0,0,0,0,0,1,0} A call site (say the static type of the call is A) will check whether the object's vtable falls in the range [_ZTV1A, _ZTV1C], and is sizeof(void *)-aligned. It would then load the (vtable-_ZTV1A)/sizeof(void *)'th entry in A's bitset, which will be 1 if the vtable is valid for A. We are now faced with a number of implementation questions: how do we represent these (potentially partial) bit sets in LLVM, and how do we arrange to lay out the globals and build the complete bit sets? Remember that classes B and C may be in differe...

...ounds like going through metadata for the LTO-only proof-of-concept > would be preferable, even if more complex. Peter, how more complex would > that be? I was just thinking about how the metadata-based design for this might work. We could have a named metadata global containing the list of bitset entries. Each entry would be a pair consisting of an identifier for the bitset (in this case, the mangled name of the class) and a pointer into a global (in this case, a valid vtable pointer). For example, this class hierarchy: class A { virtual void f(); }; class B : A { virtual void f(); }; cla...

...0,0,0,0,0,1,0} >> >> A call site (say the static type of the call is A) will check whether the >> object's vtable falls in the range [_ZTV1A, _ZTV1C], and is sizeof(void >> *)-aligned. It would then load the (vtable-_ZTV1A)/sizeof(void *)'th entry >> in A's bitset, which will be 1 if the vtable is valid for A. >> >> We are now faced with a number of implementation questions: how do we >> represent >> these (potentially partial) bit sets in LLVM, and how do we arrange to lay >> out the globals and build the complete bit sets? Rem...

...for the LTO-only proof-of-concept > > would be preferable, even if more complex. Peter, how more complex would > > that be? > > I was just thinking about how the metadata-based design for this might > work. > > We could have a named metadata global containing the list of bitset > entries. > Each entry would be a pair consisting of an identifier for the bitset (in > this case, the mangled name of the class) and a pointer into a global > (in this case, a valid vtable pointer). > > For example, this class hierarchy: > > class A { virtual void f(); };...

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...

...sks are leftovers that need to be updated to remove the limitation on the number of enum attributes that can be defined in the Attribute::AttrKind enum. Per a suggestion that I received a while ago from Reid Kleckner (on the llvm-dev list), I propose to implement both of these data members as std::bitset objects. Here are the details for this proposed change: llvm/lib/IR/AttributeImpl.h<https://sdocc.itg.ti.com/ui#file:review=11893/version=393846>: - Define AvailableAttrs and AvailableFunctionAttrs with type std::bitset<AttributeEndAttrKinds> instead of uint64_t - Update AttributeSetN...

...I consider writing a R package on statistics for the sorting method as a hobby. I have written a private Java application that I could use as a basis. Therefore I'd like to ask two questions: 1) logical vectors: Bit storage (small) and capable of bit operations? The Java application relies on BitSet(s) for efficiency reasons. Arrays of logical values cost far too much memory (in the 2nd level heap etc.) while chunks of BitSets easily fit into the first processor cache. Moreover the Bit operations or, xor, and, andnot, cardinality, clone, flip, equals, intersects are much faster done for BitSet...

...15 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? >...

...0,0,0} > C = {0,0,0,0,0,0,1,0} > > A call site (say the static type of the call is A) will check whether the > object's vtable falls in the range [_ZTV1A, _ZTV1C], and is sizeof(void > *)-aligned. It would then load the (vtable-_ZTV1A)/sizeof(void *)'th entry > in A's bitset, which will be 1 if the vtable is valid for A. > > We are now faced with a number of implementation questions: how do we represent > these (potentially partial) bit sets in LLVM, and how do we arrange to lay > out the globals and build the complete bit sets? Remember that classes B &gt...

Trying to summarize all opinions expressed here: Peter is proposing an initial implementation that would only work with LTO. Folks seem put off by this implementation affecting IR without having proven itself, and having shortcomings (as Jim pointed out). Kostya proposed going through metadata (and Chris kind of did too by mentioning tbaa), but Peter points out that this will make the

...wrote: > I don’t think that adding an IR construct for this is the way to go. You’re making IR complicated for everyone to serve a very narrow use case (one that admittedly I don’t really understand). > Also, your patch is incomplete. Presumably you have to scatter checks for “if (!GV->isBitSet())” throughout the optimizer, codegen and other things that touch globals. I'll address these points simultaneously because I would like to explain why extensive support for the new construct is not required, and why the maintenance burden is not as large as it might seem (and why my patch doe...

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? >> >> C...

...> > > would be preferable, even if more complex. Peter, how more complex would > > > that be? > > > > I was just thinking about how the metadata-based design for this might > > work. > > > > We could have a named metadata global containing the list of bitset > > entries. > > Each entry would be a pair consisting of an identifier for the bitset (in > > this case, the mangled name of the class) and a pointer into a global > > (in this case, a valid vtable pointer). > > > > For example, this class hierarchy: > > &...

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

Hi all, The bitset metadata currently used in LLVM has a few problems: 1. It has the wrong name. The name "bitset" refers to an implementation detail of one use of the metadata (i.e. its original use case, CFI). This makes it harder to understand, as the name makes no sense in the context of virtual call o...

...pop %rbx 255a8fa: c3 retq ==LLVM IR-level design== Given a class name, how can we determine the closed set of derived classes and possible function pointers for a call site? As it turns out the IR already has a way of expressing this information: bitsets [1], which are already being used to implement CFI. We can encode the information for devirtualization by combining the @llvm.bitset.test and @llvm.assume intrinsics. %vtable = load i8**, i8*** %obj %p = call i1 @llvm.bitset.test(%vtable, “Base”) call void @llvm.assume(i1 %p) ; %vtable is assumed...

> On Jan 29, 2015, at 6:50 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > 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 <http://reviews.llvm.org/D7288> Hi Peter, I don’t think that adding an IR construct for this is the way to go. You’re making IR complicated for everyone to s...

...n Tue, Feb 03, 2015 at 04:03:45PM -0800, Sean Silva wrote: > One other thing: if this can be used for control-flow integrity, I assume > it has to have good knowledge of the available indirect call targets. Could > we also use this information for devirtualization? I would expect so. If a bitset contains only one element, we should be able to teach the lowering pass to simply test that the given pointer is equal to that element (i.e. the only valid vptr). If the later IR branches to a trapping block if that condition is false, it should be possible for the optimizer to deduce that the cond...

...escriptor) to abstract a memory location.  MD contains 4 main fields: id, base, offset, size. For these special MD (ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY),  we give them id 1, 2, 3, 4, that means MD1 is ALL_MEMORY, MD2 is GLOBAL_MEMORY, the same goes for the rest.  Then we maintain a BITSET class to encapsulate the 'union', 'intersect', 'diff' etc to simply the operations bewteen special  MD and other general MDs. e.g: union operation bewteen special MD and general MD. Given BITSET a, b; a={MD1} b={MD10} c={MD20} Here MD10, MD20 are general MD....

...tract a memory location. > MD contains 4 main fields: id, base, offset, size. > For these special MD (ALL_MEMORY, GLOBAL_MEMORY, STACK_MEMORY, HEAP_MEMORY), > we give them id 1, 2, 3, 4, that means MD1 is ALL_MEMORY, MD2 is GLOBAL_MEMORY, the same goes for the rest. > Then we maintain a BITSET class to encapsulate the 'union', 'intersect', 'diff' etc to simply the operations bewteen special > MD and other general MDs. Okay. > e.g: union operation bewteen special MD and general MD. > > Given BITSET a, b; > a...