Peter Collingbourne
2015-Feb-04 00:13 UTC
[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>
Peter Collingbourne
2015-Feb-04 00:33 UTC
[LLVMdev] IR extension proposal: bitset constants
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