similar to: ThinLTO + CFI

Displaying 20 results from an estimated 7000 matches similar to: "ThinLTO + CFI"

2018 Apr 17
0
ThinLTO + CFI
I watched Teresa’s talk on ThinLTO from last year’s CppCon, and it sounded like adding global variable information to the summaries was in the works, or at least in planning. Can someone (Teresa?) please share the current status? If it’s part of future plans, are there any specific proposals that can be picked up and worked on? Thanks! > On Apr 9, 2018, at 6:51 PM, via llvm-dev <llvm-dev
2018 Apr 17
3
ThinLTO + CFI
Hi Dmitry, Sorry for the late reply. For CFI specific code generation, pcc is a better person to answer. But on the issue of global variables being optimized, that hasn't happened yet. That would be great if you wanted to pick that up! In your original email example, it seems like the file static i=53 could be constant propagated since there are no other defs, and the code in get_fptr
2018 Apr 18
0
ThinLTO + CFI
Hi Teresa, Thanks for the info! This example is my attempt to reduce FreeBSD kernel to something more manageable :) I will take a look at why globals are not being imported in this case. What’s the best tool to look into ThinLTO objects and their summaries? Most dumping tools don’t seem to like ThinLTO bitcode files… Hopefully Peter can chime in regarding CFI related issues. Thanks. Dmitry.
2018 Apr 19
3
ThinLTO + CFI
On Wed, Apr 18, 2018 at 4:49 PM, <dmitry.mikulin at sony.com> wrote: > Hi Teresa, > > Thanks for the info! > This example is my attempt to reduce FreeBSD kernel to something more > manageable :) > > I will take a look at why globals are not being imported in this case. > What’s the best tool to look into ThinLTO objects and their summaries? Most > dumping tools
2018 Apr 26
0
ThinLTO + CFI
Hi Peter, We could probably tolerate a certain amount of unused jump table entries. However, I just realized that all non-inline imported calls end up going through a jump table entry. Is that correct? Initially I thought you meant calls promoted from indirect. While this can be fixed by replacing direct calls to jump tables with direct calls to real targets, I found other cases where ThinLTO+CFI
2018 Apr 20
2
ThinLTO + CFI
Regarding the orderfile, yes, I was thinking more about ordering the real functions. In that case it sounds like your best option may be to implement the optimization pass to make direct calls go directly to the real function. >From a performance perspective I don't think it would make much difference if there are unused jump table entries. Peter On Thu, Apr 19, 2018 at 6:09 PM, via
2018 Apr 20
0
ThinLTO + CFI
Teresa, Peter, Thanks for your help! I need to re-run my experiments as the compiler I used did not have the latest changes like r327254. The fact that the decision about routing calls through jump table entries is made early may be problematic. In my experiments with FreeBSD kernel, ThinLTO produced thousands jump table entries compared to only dozens with full LTO. As for re-ordering jump table
2018 Apr 27
0
ThinLTO + CFI
For the test case below, I get the following IR for main() on entry to ThinLTO backend invocation of LowerTypeTestsModule::lower(). This is after I moved this pass down in the pipeline so it’s invoked after inlining. The declarations for foo() and bar() are read in at the time of module import, Importer.importFunctions() in lto::thinBackend(). They do not have type metadata attached to them. In
2018 May 14
1
ThinLTO + CFI
I’m looking at this problem again. In ThinLTO backend, the types of symbols like foo() and bar() get constructed from CfiFunctionDefs and CfiFunctionDelcs of the summary. The summary does not have the type metadata for these. That’s why we can’t do type matching in LowerTypeTestsModule to potentially eliminate type checks. Would it be reasonable to add type metadata to the CFI part of the summary
2018 Apr 27
3
ThinLTO + CFI
> We could probably tolerate a certain amount of unused jump table entries. However, I just realized that all non-inline imported calls end up going through a jump table entry. Is that correct? In fact it is all calls that go through a function pointer type that is used anywhere in the program for an indirect call, but depending on your program that could be very close to "yes".
2018 May 01
0
ThinLTO + CFI
Hi Dmitry, the direct call patch seems like a good start; however, by falling through to the F->replaceUsesExceptBlockAddr(FDecl) at the bottom of LowerTypeTestsModule::importFunction() I believe it will replace all uses of a function (for a definition outside the TU it's defined in) with the direct function reference instead of just direct calls. Also, I believe the logic for
2018 May 01
0
ThinLTO + CFI
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 > “foo.cfi” next to each other in link order, because if both exist, the > linker
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 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 Apr 30
4
ThinLTO + CFI
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 “foo.cfi” next to each other in link order, because if both exist, the linker reorders the jump table next to the real function. This is not what we want when the goal is to get rid
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
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
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
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
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