search for: vcall

...tual functions), and > you're more likely to inline the constructor and devirtualize the > call. I don't have any real data to back up that this will materially > help, though. Sanjoy, this is a good example. The code pattern is basically like this: Worker(Base *B) { B->vCall(); } Factory::create(Kind K) { if (K == ..) return new D1(); else ... } Caller() { .. Base *B = Factory::create(K, ...); Worker(B); } The added ordering constraints from Factory::create() node to all virtual methods in Base's hierarchy ensures that after 1) Factory::create...

...ther than being directly associated with a global. This makes it harder to manipulate the metadata when rebuilding global variables, summarise it as part of ThinLTO and drop unused metadata when associated globals are dropped. For this reason, CFI does not currently work correctly when both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable globals, and fails to associate metadata with the rebuilt globals. As I understand it, the same problem could also affect ASan, which rebuilds globals with a red zone. I would like to solve both of these problems in the following way: 1. Renam...

...n value handling from within these macros. This is fairly * cumbersome. * - * There are 5 sets of PVOP_* macros for dealing with 0-4 arguments. - * It could be extended to more arguments, but there would be little - * to be gained from that. For each number of arguments, there are - * the two VCALL and CALL variants for void and non-void functions. + * There are 5 sets of PVOP_* macros for dealing with 0-5 arguments. + * For each number of arguments, there are the two VCALL and CALL + * variants for void and non-void functions. * * When there is a return value, the invoker of the macro mu...

...n value handling from within these macros. This is fairly * cumbersome. * - * There are 5 sets of PVOP_* macros for dealing with 0-4 arguments. - * It could be extended to more arguments, but there would be little - * to be gained from that. For each number of arguments, there are - * the two VCALL and CALL variants for void and non-void functions. + * There are 5 sets of PVOP_* macros for dealing with 0-5 arguments. + * For each number of arguments, there are the two VCALL and CALL + * variants for void and non-void functions. * * When there is a return value, the invoker of the macro mu...

Hi Peter, Thanks for sending this and sorry for the slow response. Some questions below. Teresa On Tue, Oct 25, 2016 at 5:27 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > > As promised, here is a brain dump on how I see CFI for vcalls working > under ThinLTO. Most of this has been prototyped, so the design does appear > to be sound. For context on how CFI currently works under regular LTO, > please read: > > http://llvm.org/docs/TypeMetadata.html > http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html &gt...

Hi all, As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. The next step is to think about what the A...

On Fri, Jun 17, 2016 at 12:27 AM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, Jun 17, 2016 at 12:10 AM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Thu, Jun 16, 2016 at 11:51 PM, Sean Silva <chisophugis at gmail.com> >> wrote: >> >>> >>> >>> On Thu, Jun 16, 2016 at 11:07

Hi all, As promised, here is a brain dump on how I see CFI for vcalls working under ThinLTO. Most of this has been prototyped, so the design does appear to be sound. For context on how CFI currently works under regular LTO, please read: http://llvm.org/docs/TypeMetadata.html http://clang.llvm.org/docs/ControlFlowIntegrityDesign.html http://clang.llvm.org/docs/LTOVi...

...ote: > >> > >> > >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> > >> Hi all, > >> > >> As mentioned in my recent RFC entitled "RFC: a more detailed design for > >> ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files > >> to contain multiple modules. In https://reviews.llvm.org/D24786 I took > a > >> step towards that by proposing a change to the module format so that the > >> block info block is stored at the t...

...ver, I solved my issue by finding that the BitCastInst used when outlining OpenMP parallel region offers a method for retrieving the original value within the bitcast via stripPointerCasts(). So what I did to retrieve omp_outlined..45 is: //bitcast is the third argument of __kmpc_fork_call Value *vcall = callInst->getArgOperand(2); //This will return the outlined function in __kmpc_fork_call Function *f = dyn_cast<Function>(vcall->stripPointerCasts()); f->getName returns ".omp_outlined..45" So this worked. Thanks again, Dounia On Sat, Jul 30, 2016 at 6:47 PM, Arpith C...

On Tue, Oct 25, 2016 at 8:36 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for > ThinLTO + vcall CFI" I would like to introduce the ability for bitcode > files to contain multiple modules. In https://reviews.llvm.org/D24786 I > took a step towards that by proposing a change to the module format so that > the block info block is stored at the top level. The next step is to think &...

> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi all, > > As mentioned in my recent RFC entitled "RFC: a more detailed design for ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files to contain multiple modules. In https://reviews.llvm.org/D24786 <https://reviews.llvm.org/D24786> I took a step towards that by proposing a change to the module format so that the block info block is stored at the top level. Th...

...hdi Amini <mehdi.amini at apple.com> wrote: >> >> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi all, >> >> As mentioned in my recent RFC entitled "RFC: a more detailed design for >> ThinLTO + vcall CFI" I would like to introduce the ability for bitcode files >> to contain multiple modules. In https://reviews.llvm.org/D24786 I took a >> step towards that by proposing a change to the module format so that the >> block info block is stored at the top level. The next step i...

...> >> On Oct 25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> >> >> wrote: >> >> >> >> Hi all, >> >> >> >> As mentioned in my recent RFC entitled "RFC: a more detailed design for >> >> ThinLTO + vcall CFI" I would like to introduce the ability for bitcode >> >> files >> >> to contain multiple modules. In https://reviews.llvm.org/D24786 I took >> >> a >> >> step towards that by proposing a change to the module format so that >> >> t...

...25, 2016, at 6:28 PM, Peter Collingbourne <peter at pcc.me.uk> >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> As mentioned in my recent RFC entitled "RFC: a more detailed design for >>>>> ThinLTO + vcall CFI" I would like to introduce the ability for bitcode >>>>> files >>>>> to contain multiple modules. In https://reviews.llvm.org/D24786 I took >>>>> a >>>>> step towards that by proposing a change to the module format so that >&gt...

...hufflevector <4 x i32> %broadcast.splatinsert6, <4 x i32> undef, <4 x i32> zeroinitializer, !dbg !7 %induction8 = add <4 x i32> %broadcast.splat7, <i32 0, i32 1, i32 2, i32 3>, !dbg !7 %1 = sitofp <4 x i32> %induction8 to <4 x float>, !dbg !7 %vcall = call <4 x float> @__svml_sinf4_ha(<4 x float> %1) %2 = getelementptr inbounds float, float* %array, i64 %index, !dbg !8 %3 = bitcast float* %2 to <4 x float>*, !dbg !9 store <4 x float> %vcall, <4 x float>* %3, align 4, !dbg !9, !tbaa !10 %index.next = add i6...

...c.me.uk <mailto:peter at pcc.me.uk>> >>>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> As mentioned in my recent RFC entitled "RFC: a more detailed design for >>>>>> ThinLTO + vcall CFI" I would like to introduce the ability for bitcode >>>>>> files >>>>>> to contain multiple modules. In https://reviews.llvm.org/D24786 <https://reviews.llvm.org/D24786> I took >>>>>> a >>>>>> step towards that by...

...hufflevector <4 x i32> %broadcast.splatinsert6, <4 x i32> undef, <4 x i32> zeroinitializer, !dbg !7 %induction8 = add <4 x i32> %broadcast.splat7, <i32 0, i32 1, i32 2, i32 3>, !dbg !7 %1 = sitofp <4 x i32> %induction8 to <4 x float>, !dbg !7 %vcall = call <4 x float> @__svml_sinf4_ha(<4 x float> %1) %2 = getelementptr inbounds float, float* %array, i64 %index, !dbg !8 %3 = bitcast float* %2 to <4 x float>*, !dbg !9 store <4 x float> %vcall, <4 x float>* %3, align 4, !dbg !9, !tbaa !10 %index.next = add i6...

...elative ABI. That bug gives more details and justification for that ABI. The user interface for the new ABI would be that -fwhole-program-vtables would take an optional value indicating which aspects of the program have whole-program scope. For example, the existing implementation of whole-program vcall optimization allows external code to call into translation units compiled with -fwhole-program-vtables, but does not allow external code to derive from classes defined in such translation units, so you could request the current behaviour with "-fwhole-program-vtables=derive", which means...

...etails and > justification for that ABI. > > The user interface for the new ABI would be that -fwhole-program-vtables > would take an optional value indicating which aspects of the program have > whole-program scope. For example, the existing implementation of > whole-program > vcall optimization allows external code to call into translation units > compiled with -fwhole-program-vtables, but does not allow external code to > derive from classes defined in such translation units, so you could request > the current behaviour with "-fwhole-program-vtables=derive&quot...