similar to: Identify virtual function call sites and candidate callees for it

Displaying 20 results from an estimated 2000 matches similar to: "Identify virtual function call sites and candidate callees for it"

2017 Mar 28
2
llvm 3.9 Alias Analysis result for function's by-ref arguments
Hi, I'm writing an analysis pass which is supposed to find instructions in a function that modify function's by-ref arguments. For that I'm using llvm AliasAnalysis pass, particularly querying for ModRef info for instructions and function arguments, to see if a given instruction modifies a given argument. However, for functions with more than one by-ref argument, I get strange
2018 Aug 10
2
llvm MemorySSA def-use chains
Hi, try adding some alias analysis to the pipeline: see examples in llvm/test/Analysis/MemorySSA/*.ll for example assume.ll has ; RUN: opt -aa-pipeline=basic-aa -passes='print<memoryssa>,verify<memoryssa>' without basic-aa the memory ssa will safely assume that the stores to %a and %d alias which may be proven disjoint by one of the alias analyses. On Thu, Aug 9, 2018 at 8:37
2018 Aug 09
2
llvm MemorySSA def-use chains
Hi, I have a question about how llvm MemorySSA works, as seems I misunderstand something. Consider following code snippet and corresponding IR with MemorySSA annotations (got with opt -print-memoryssa) void foo(int* b) { int a = 0; int d = 12; if (b) { a = 42; d = 32; } int c = a; int e = d; } ; Function Attrs: noinline nounwind optnone uwtable
2016 May 04
4
RFC [ThinLTO]: An embedded summary encoding to support CFI and vtable opt
Hi all, I wanted to make this proposal to extend ThinLTO to allow a bitcode module to embed another bitcode module containing summary information. The purpose of doing so is to support CFI and whole-program devirtualization optimizations under ThinLTO. Overview The CFI and whole-program devirtualization optimizations work by transforming vtables according to the class hierarchy. For example,
2017 May 16
2
[RFC] CFI for indirect calls with ThinLTO
Hi, this is a proposal for the implementation of CFI-icall [1] with ThinLTO. Jumptables are generated in the merged module. To generate a jumptable, we need a list of functions with !type annotations, including (in non-cross-dso mode) external functions. Unfortunately, LLVM IR does not preserve unused function declarations, and we don’t want to copy the actual function bodies to the merged
2018 Apr 24
8
RFC: LLVM Assembly format for ThinLTO Summary
Hi everyone, I started working on a long-standing request to have the summary dumped in a readable format to text, and specifically to emit to LLVM assembly. Proposal below, please let me know your thoughts. Thanks, Teresa *RFC: LLVM Assembly format for ThinLTO
2017 May 16
2
[RFC] CFI for indirect calls with ThinLTO
On Mon, May 15, 2017 at 6:44 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Thanks for sending this out. A few comments below. > > On Mon, May 15, 2017 at 5:17 PM, Evgenii Stepanov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> this is a proposal for the implementation of CFI-icall [1] with ThinLTO. >> >>
2018 May 01
2
ThinLTO + CFI
> On Apr 30, 2018, at 6:04 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 30, 2018 at 1:05 PM, <dmitry.mikulin at sony.com> wrote: > Replacing direct calls to jump table entries with calls to real targets recovers most of the performance loss in my benchmark. Dealing with link order files is a bit cumbersome though: I can’t keep both, say “foo” and
2018 Apr 30
2
RFC: LLVM Assembly format for ThinLTO Summary
Hi Peter, Thanks for your comments, replies below. Teresa On Wed, Apr 25, 2018 at 2:08 PM Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi Teresa, > > Thanks for sending this proposal out. > > I would again like to register my disagreement with the whole idea of > writing summaries in LLVM assembly format. In my view it is clear that this > is not the right
2018 May 01
2
ThinLTO + CFI
It’s not the functions themselves, it’s the jump tables that end up in the same section of the thin-link temporary object. If I have, say, foo and bar and both of them need a jump table entry, both entries will be in the same section of the temp object. The real functions will be renamed to foo.cfi and bar.cfi. If I list “foo.cfi, foo, bar.cfi, bar” in the link order file, the linker (I use lld)
2018 May 01
2
ThinLTO + CFI
That seems to do the trick. I get “symbol ordering file: no such symbol: <blah>” warnings for symbols that didn’t get renamed. Maybe we'll have a separate order file for CFI builds... What about the comment above that line? > On May 1, 2018, at 11:46 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at
2018 May 01
2
ThinLTO + CFI
Jump table sections already have this prefix: ".text..L.cfi.jumptable.”, without forcing the name with setSection(). Is that good enough? > On May 1, 2018, at 1:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text
2018 May 03
2
RFC: LLVM Assembly format for ThinLTO Summary
On Thu, May 3, 2018 at 2:58 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi Teresa, > > I have re-read your proposal, and I'm not getting how you plan to > represent combined summaries with this. Unless I'm missing something, there > doesn't seem to be a way to write out summaries that is independent of the > global values that they relate to. Is that
2018 May 01
3
RFC: LLVM Assembly format for ThinLTO Summary
On Mon, Apr 30, 2018 at 10:21 AM Peter Collingbourne <peter at pcc.me.uk> wrote: > On Mon, Apr 30, 2018 at 8:32 AM, Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi Peter, >> Thanks for your comments, replies below. >> Teresa >> >> On Wed, Apr 25, 2018 at 2:08 PM Peter Collingbourne <peter at pcc.me.uk> >> wrote: >>
2018 May 01
0
ThinLTO + CFI
On Tue, May 1, 2018 at 11:10 AM, <dmitry.mikulin at sony.com> wrote: > > > > On Apr 30, 2018, at 6:04 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > > > On Mon, Apr 30, 2018 at 1:05 PM, <dmitry.mikulin at sony.com> wrote: > > Replacing direct calls to jump table entries with calls to real targets > recovers most of the performance
2018 May 01
0
ThinLTO + CFI
On Tue, May 1, 2018 at 11:29 AM, <dmitry.mikulin at sony.com> wrote: > It’s not the functions themselves, it’s the jump tables that end up in the > same section of the thin-link temporary object. If I have, say, foo and bar > and both of them need a jump table entry, both entries will be in the same > section of the temp object. The real functions will be renamed to foo.cfi >
2018 May 01
3
RFC: LLVM Assembly format for ThinLTO Summary
Hi, My main concern is this one: > Currently, I am emitting the summary entries at the end, after the metadata nodes. Note that the ModuleSummaryIndex is not currently referenced from the Module, and isn’t currently created when parsing the Module IR bitcode (there is a separate derived class for reading the ModuleSummaryIndex from bitcode). This is because they are not currently used at the
2018 May 01
0
ThinLTO + CFI
I think we just need to change the section name for non-MachO object formats because "__TEXT,__text,regular,pure_instructions" is the default text section name in MachO. There seems to be a way to get the ".cfi" suffix on section names that doesn't involve setting a custom section name (which would invoke the "everything goes in the same section" behaviour), and
2018 May 01
0
ThinLTO + CFI
The problem as I recall was that we do not want jumptable sections to appear before __cfi_check, so we gave these jump tables a name so that the bfd default linker script would sort them after __cfi_check. This is the relevant part of the default linker script: .text : { [...] *(.text.hot .text.hot.*) *(.text .stub .text.* .gnu.linkonce.t.*) } So I guess the idea was
2018 Apr 30
0
RFC: LLVM Assembly format for ThinLTO Summary
On Mon, Apr 30, 2018 at 8:32 AM, Teresa Johnson <tejohnson at google.com> wrote: > Hi Peter, > Thanks for your comments, replies below. > Teresa > > On Wed, Apr 25, 2018 at 2:08 PM Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> Hi Teresa, >> >> Thanks for sending this proposal out. >> >> I would again like to register my