similar to: LTO renaming of constants with inline assembly

On Wed, Apr 6, 2016 at 10:46 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > I suspect that the right way to do promotion/renaming of this sort is to > rename at the MC layer just before writing the symbol table to the object > file. > I think that is too late - how would the symbols be distinguished in the LTO case below after the IR is linked but before we renamed the

On Wed, Apr 6, 2016 at 11:16 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Wed, Apr 6, 2016 at 10:49 AM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Wed, Apr 6, 2016 at 10:46 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> I suspect that the right way to do promotion/renaming of this

I still wonder if this would be an issue in _standard_ (not thin) LTO? This test seems to be OK on my (slightly modified) standard LTO flow, but I do wonder for a more general case. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Collingbourne

On 20 October 2017 at 09:24, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range below

On 20 October 2017 at 09:24, Ingo Molnar <mingo at kernel.org> wrote: > > * Thomas Garnier <thgarnie at google.com> wrote: > >> Change the assembly code to use only relative references of symbols for the >> kernel to be PIE compatible. >> >> Position Independent Executable (PIE) support will allow to extended the >> KASLR randomization range below

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce dynamic relocation space on mapped memory. It also simplifies the relocation process. - Move the start the module section next to the kernel. Remove the need for -mcmodel=large on modules. Extends

Changes: - patch v3: - Update on message to describe longer term PIE goal. - Minor change on ftrace if condition. - Changed code using xchgq. - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

These patches make the changes necessary to build the kernel as Position Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below the top 2G of the virtual address space. It allows to optionally extend the KASLR randomization range from 1G to 3G. Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler changes, PIE support and KASLR in general. Thanks to

Change the assembly code to use only relative references of symbols for the kernel to be PIE compatible. Position Independent Executable (PIE) support will allow to extended the KASLR randomization range below the -2G memory limit. Signed-off-by: Thomas Garnier <thgarnie at google.com> --- arch/x86/crypto/aes-x86_64-asm_64.S | 45 ++++++++----- arch/x86/crypto/aesni-intel_asm.S

This set of patches converts the way frames gets created from using PUSHes/POPs to using MOVes, thus allowing (in certain cases) to avoid saving/restoring part of the register set. While the place where the (small) win from this comes from varies between CPUs, the net effect is a 1 to 2% reduction on a combined interruption entry and exit when the full state save can be avoided. 1: use MOV

I am running into a problem with 'i1*' as a function's argument which seems to have appeared since I switched to LLVM 3.6 (but can have other source, of course). If I look at the assembler that the MCJIT generates for an x86-64 target I see that the array 'i1*' is taken as a sequence of 1 bit wide elements. (I guess that's correct). However, I used to call the function

Hi, Thanks for the info, If i only want to run performance test on benchmarks for LTO and Thin LTO enabled target, Can u suggest ways to do it ? I want to do it at my end. Thanks, Siddharth On Wed, May 2, 2018 at 7:03 PM, Teresa Johnson <tejohnson at google.com> wrote: > I've only measured performance on x86. There are some old results for SPEC > cpu2006 in the blog post here:

No worries, thanks for the update. Teresa On Mon, Sep 26, 2016, 7:16 AM Carsten Mattner <carstenmattner at gmail.com> wrote: > On Mon, Sep 26, 2016 at 3:52 PM, Teresa Johnson <tejohnson at google.com> > wrote: > > > > ThinLTO needs to create as many temporary files as there are input > > modules to the link. From your 'ls' below, it doesn't look

Yes running LLVM performance test suite with LTO and Thin LTO enabled. Thanks, Siddharth On Fri, May 11, 2018 at 7:32 PM, Teresa Johnson <tejohnson at google.com> wrote: > I'm not completely sure what you are asking. Are you looking for > performance benchmarks to use for LTO and ThinLTO testing? Or are you > asking how to build/run with LTO and ThinLTO? Are you asking how to

I'm not completely sure what you are asking. Are you looking for performance benchmarks to use for LTO and ThinLTO testing? Or are you asking how to build/run with LTO and ThinLTO? Are you asking how to run LLVM's performance test-suite with LTO and ThinLTO? Teresa On Fri, May 11, 2018 at 5:21 AM Siddharth Shankar Swain < h2015096 at pilani.bits-pilani.ac.in> wrote: > Hi, >

Hi Teresa, Actually, enabling the new pass manager manually seems to have solved this issue, so this problem is only valid for the old pass manager. Thanks, Graham Yiu LLVM Compiler Development IBM Toronto Software Lab Office: (905) 413-4077 C2-707/8200/Markham Email: gyiu at ca.ibm.com From: Teresa Johnson <tejohnson at google.com> To: Graham Yiu <gyiu at ca.ibm.com> Cc: