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

On 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 condition is true in any code that is dominated
by the branch, and from that do devirtualization.

Thanks,
-- 
Peter

On Tue, Feb 3, 2015 at 4:13 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> On 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 condition is true in any code that is
> dominated
> by the branch, and from that do devirtualization.
>

Well, I was wondering about for devirtualization without necessarily
needing any of the CFI stuff. We should probably aim for a design that
provides a primitive that can satisfy the needs of both CFI and
devirtualization.

-- Sean Silva

>
> Thanks,
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150203/3caf61e3/attachment.html>

On Tue, Feb 03, 2015 at 04:26:16PM -0800, Sean Silva
wrote:
> On Tue, Feb 3, 2015 at 4:13 PM, Peter Collingbourne <peter at
pcc.me.uk> wrote:
> 
> > On 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 condition is true in any code that is
> > dominated
> > by the branch, and from that do devirtualization.
> >
> 
> 
> Well, I was wondering about for devirtualization without necessarily
> needing any of the CFI stuff. We should probably aim for a design that
> provides a primitive that can satisfy the needs of both CFI and
> devirtualization.
A client that doesn't need CFI could emit IR that looks like this:

%pred = call i1 @llvm.bitset.test(i8* %vptr, metadata !"some_bitset")
call void @llvm.assume(i1 %pred)
; make the call in the normal way

and from that we should be able to lower to the same type of IR for
single-element bitsets and make the same sort of deduction. (The lowering
pass could avoid emitting bitsets unless the call is used by something other
than a call to llvm.assume.)

Thanks,
-- 
Peter