search for: thinlink

...count equally among them. For functions in a non-trivial SCC, the algorithm has to ensure that the counts are stable and deterministic. In ThinLTO mode, the function summary contains the list of call edges from the function. We propose to add the relative block frequency on these edges. During the thinlink phase, we propagate the function counts on the entire call graph and update the function summary with the synthetic counts. Additionally, we plan to use the computed counts to drive the importing decisions. Alternative approach ----------------------------- An alternative to generating syntheti...

.... > > Currently there is no easy way to get symbol information out of > bitcode files. One has to read the module and mangle the names. This > has a few problem > This would be great for ThinLTO as well: > > * During lto we have to create the Module earlier. > During the ThinLink step we could avoid creating the Module altogether, only the parallel backends would need the Module. > * There is no convenient spot to store flags/summary. > Right now we are duplicating some info like the linkage type into the summary since it isn't available in the ValueSymbolTable...

...non-trivial SCC, the algorithm has to ensure that the counts are stable and >> deterministic. >> >> In ThinLTO mode, the function summary contains the list of call edges >> from the function. We propose to add the relative block frequency on these >> edges. During the thinlink phase, we propagate the function counts on the >> entire call graph and update the function summary with the synthetic >> counts. Additionally, we plan to use the computed counts to drive the >> importing decisions. >> >> Alternative approach >> >> --------...

This is about https://llvm.org/bugs/show_bug.cgi?id=27551. Currently there is no easy way to get symbol information out of bitcode files. One has to read the module and mangle the names. This has a few problem * During lto we have to create the Module earlier. * There is no convenient spot to store flags/summary. * Simpler tools like llvm-nm have massive dependencies because Object depends on MC

...nsure that the counts are stable and >>>> deterministic. >>>> >>>> In ThinLTO mode, the function summary contains the list of call edges >>>> from the function. We propose to add the relative block frequency on these >>>> edges. During the thinlink phase, we propagate the function counts on the >>>> entire call graph and update the function summary with the synthetic >>>> counts. Additionally, we plan to use the computed counts to drive the >>>> importing decisions. >>>> >>>> Alterna...

...Link will need to be split out and done before any Full LTO optimization/codegen. E.g., if we are importing from FullLTO into ThinLTO, then some symbols will need to be promoted in the Full LTO IR. And to import from ThinLTO into FullLTO, we will also need to have the Thin Link results. Either the ThinLink + ThinLTO optimizations like importing/promotion would need to be done before any Full LTO IR merging + backend, or as Mehdi suggests, do the Full LTO IR merging, then treat as a new ThinLTO IR object during the ThinLink and beyond. For distributed builds, we would need to serialize out the Full LT...

...;>>>>> deterministic. >>>>>> >>>>>> In ThinLTO mode, the function summary contains the list of call edges >>>>>> from the function. We propose to add the relative block frequency on these >>>>>> edges. During the thinlink phase, we propagate the function counts on the >>>>>> entire call graph and update the function summary with the synthetic >>>>>> counts. Additionally, we plan to use the computed counts to drive the >>>>>> importing decisions. >>>>&...

...Link will need to be split out and done before any Full LTO optimization/codegen. E.g., if we are importing from FullLTO into ThinLTO, then some symbols will need to be promoted in the Full LTO IR. And to import from ThinLTO into FullLTO, we will also need to have the Thin Link results. Either the ThinLink + ThinLTO optimizations like importing/promotion would need to be done before any Full LTO IR merging + backend, or as Mehdi suggests, do the Full LTO IR merging, then treat as a new ThinLTO IR object during the ThinLink and beyond. For distributed builds, we would need to serialize out the Full LT...

Hi all, At some time in the near future we would like to allow for Rust to use the new PM. As I understand it, Rust uses LLVM through the stable LLVM C API, which currently only provides an interface to the legacy PM. We wanted to ask what people think about how we should go about exposing the new PM through this API. We can think of 3 possibilities for now: 1) Just replace the API to expose the

I am nearing the end of a project that moved our disparate services and hosts onto kvm virtualized servers. What I am now contemplating is setting up my desktop as a virtual host and using one of the guests as my primary workstation. However, I am not sure how this would work in practice. I am accustomed to working with virtual instances via ssh (a terminal window) and with my desktop system in

Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit : > Hi Mehdi, > > > > Awesome! It’s a very clear design. The only question left is which > pipeline to choose for unified compile-phase optimization pipeline. > > - ThinLTO compile-phase pipeline? It might very negatively affect > compile-time and the memory footprint for FullLTO link-phase.

Hi Mehdi, Awesome! It’s a very clear design. The only question left is which pipeline to choose for unified compile-phase optimization pipeline. - ThinLTO compile-phase pipeline? It might very negatively affect compile-time and the memory footprint for FullLTO link-phase. That was the reason why so many optimization were moved from the link-phase to the parallel compile-phase for FullLTO