Re: plugin-api.h patch to add a new interface for linker plugins

Ping. Is this alright to apply now or should I wait for Stage 1? * plugin-api.h (ld_plugin_get_wrap_symbols): New plugin interface. Thanks Sri On Thu, Feb 15, 2018 at 1:52 PM, Sriraman Tallam <tmsri...@google.com> wrote: > Ping, this patch was approved for binutils by Cary

Re: plugin-api.h patch to add a new interface for linker plugins

On Fri, Dec 8, 2017 at 11:02 AM, Sriraman Tallam <tmsri...@google.com> wrote: > Patch attached. > > * plugin-api.h (ld_plugin_get_wrap_symbols): New > plugin interface. > > On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam <tmsri...@google.com> wrote: >>

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

he patch. Thanks Sri > > Thanks, > Stephen > > On Mon, Dec 11, 2017 at 2:10 PM, Sriraman Tallam <tmsri...@google.com> wrote: >> On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant <ccout...@gmail.com> wrote: >>>> include/ChangeLog: >>>> 2017-11-09 Steph

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

s patch as well, > if it's not too much trouble. I think much has changed to need a > rebase? Ok, let me apply your patch. I will get back if there are inconsistencies. Thanks Sri > > Thanks, > Stephen > > On Mon, Dec 11, 2017 at 2:10 PM, Sriraman Tallam <tmsri...@google.com>

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote: >> include/ChangeLog: >> 2017-11-09 Stephen Crane >> >> * plugin-api.h: Add new plugin hook to allow processing of input >> files added by a plugin. >>

Re: plugin-api.h patch to add a new interface for linker plugins

Patch attached. * plugin-api.h (ld_plugin_get_wrap_symbols): New plugin interface. On Fri, Dec 8, 2017 at 11:01 AM, Sriraman Tallam <tmsri...@google.com> wrote: > Hi, > >This patch was approved for binutils by Cary: > https://sourceware.org/ml/binutils/2017-12/msg00023.ht

plugin-api.h patch to add a new interface for linker plugins

Hi, This patch was approved for binutils by Cary: https://sourceware.org/ml/binutils/2017-12/msg00023.html Is it ok to apply this to GCC include/plugin-api.h ? Thanks Sri

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote: > > include/ChangeLog: > > 2017-11-09 Stephen Crane > > > > * plugin-api.h: Add new plugin hook to allow processing of input > > files added by a plugin. > >

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

On Thu, Nov 9, 2017 at 9:04 PM, Cary Coutant wrote: > > include/ChangeLog: > > 2017-11-09 Stephen Crane > > > > * plugin-api.h: Add new plugin hook to allow processing of input > > files added by a plugin. > >

Re: [PATCH] Add linker plugin API for processing plugin-added input files

On Thu, Sep 21, 2017 at 5:29 PM, Cary Coutant wrote: >> 2017-09-21 Stephen Crane >> >> * plugin-api.h: Add new hook to the plugin transfer vector to >> support assigning plugin-generated sections to unique output >> segments. >>

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Mon, Oct 5, 2015 at 2:58 PM, Sriraman Tallam <tmsri...@google.com> wrote: > On Wed, Sep 9, 2015 at 4:01 PM, Sriraman Tallam <tmsri...@google.com> wrote: >> On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam <tmsri...@google.com> wrote: >>> >>> On Tue,

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Wed, Sep 9, 2015 at 4:01 PM, Sriraman Tallam <tmsri...@google.com> wrote: > On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam <tmsri...@google.com> wrote: >> >> On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant <ccout...@gmail.com> wrote: >> >> Thank

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam <tmsri...@google.com> wrote: > > On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant <ccout...@gmail.com> wrote: > >> Thanks, will make those changes. Do you recommend a different name > >> for this flag like -fmake-c

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote: >> Thanks, will make those changes. Do you recommend a different name >> for this flag like -fmake-comdat-functions-static? > > Well, the C++ ABI refers to this as "vague linkage." It may be a bit > too long or too

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Wed, Aug 12, 2015 at 10:36 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Aug 4, 2015 at 11:43 AM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li davi

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, Aug 18, 2015 at 2:14 PM, Cary Coutant ccout...@gmail.com wrote: Based on Richard's suggestion, I have a patch to localize comdat functions which seems like a very effective solution to this problem. The text size increase is limited to the extra comdat copies generated for the

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, Aug 4, 2015 at 11:43 AM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li davi...@google.com wrote: Hm. But which options are unsafe? Also wouldn't it be better

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li davi...@google.com wrote: Hm. But which options are unsafe? Also wouldn't it be better to simply _not_ have unsafe options produce comdats but always make local

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

On Fri, Apr 17, 2015 at 5:36 AM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote: I don't like it. Nonshared libgcc is libgcc.a, period. No sense in creating yet another

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li davi...@google.com wrote: Hm. But which options are unsafe? Also wouldn't it be better to simply _not_ have unsafe options produce comdats but always make local clones for them (thus emit the comdat with unsafe flags dropped)? Always

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, Jun 4, 2015 at 10:05 AM, Richard Henderson r...@redhat.com wrote: On 06/04/2015 09:54 AM, Sriraman Tallam wrote: + DECL_ATTRIBUTES (SYMBOL_REF_DECL (XEXP(fnaddr, 0) Spacing. { use_reg (use, gen_rtx_REG (Pmode, REAL_PIC_OFFSET_TABLE_REGNUM

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Patch attached with those changes. Is this patch alright to commit? * c-family/c-common.c (noplt): New attribute. (handle_noplt_attribute): New handler. * calls.c (prepare_call_address): Check for noplt attribute. * config/i386/i386.c (ix86_function_ok_for_sibcall): Check for noplt attribute.

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Wed, Jun 3, 2015 at 1:09 PM, Richard Henderson r...@redhat.com wrote: On 06/03/2015 11:38 AM, Sriraman Tallam wrote: + { no_plt, 0, 0, true, false, false, + handle_no_plt_attribute, false }, Call it noplt. We don't add the underscore

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

I agree now that it will be much cleaner just to punt this into the backend, so it may be worth noting that making this work properly for the non-PIC case requires quite a degree of massaging in the backends. Objections withdrawn. Thanks!, I have attached the latest patch after making the

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Mon, Jun 1, 2015 at 7:01 PM, Sriraman

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Tue, Jun 2, 2015 at 12:32 PM, Bernhard Reutner-Fischer rep.dot@gmail.com wrote: On June 2, 2015 8:15:42 PM GMT+02:00, Sriraman Tallam tmsri...@google.com wrote: [] I have now modified this patch. This patch does two things: 1) Adds new generic function attribute no_plt

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Tue, Jun 2, 2015 at 1:56 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote: Why isn't it just an indirect call in the cases that would require a GOT slot and a direct call otherwise ? I'm trying to work out what's so different on each target that mandates this to be in the target

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan ramana.radhakrish...@arm.com wrote: Why isn't it just an indirect call

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 28, 2015 at 5:05 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 2:52 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam tmsri...@google.com wrote

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

+Uros On Fri, May 29, 2015 at 10:25 AM, H.J. Lu hjl.to...@gmail.com wrote: On Fri, May 29, 2015 at 10:20 AM, Sriraman Tallam tmsri...@google.com wrote: Hi HJ, Is this ok to commit? Looks good to me. But I can't approve it. -- H.J.

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Fri, May 29, 2015 at 3:24 PM, Ramana Radhakrishnan ramana@googlemail.com wrote: On Friday, 29 May 2015, Sriraman Tallam tmsri...@google.com wrote: On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka hubi...@ucw.cz wrote: * config/i386/i386.c (avoid_plt_to_call): New function

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Hi HJ, Is this ok to commit? Thanks Sri On Thu, May 28, 2015 at 11:03 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 5:05 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 2:52 PM

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka hubi...@ucw.cz wrote: * config/i386/i386.c (avoid_plt_to_call): New function. (ix86_output_call_insn): Generate indirect call for functions marked with noplt attribute. (attribute_spec ix86_attribute_): Define new attribute

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Made one more change and New patch attached. Thanks Sri On Fri, May 29, 2015 at 2:37 PM, Sriraman Tallam tmsri...@google.com wrote: On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka hubi...@ucw.cz wrote: * config/i386/i386.c (avoid_plt_to_call): New function. (ix86_output_call_insn

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 28, 2015 at 2:01 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 12:05 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam tmsri...@google.com wrote

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 28, 2015 at 12:05 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

/extend.texi: Document new attribute noplt. * gcc.target/i386/noplt-1.c: New testcase. * gcc.target/i386/noplt-2.c: New testcase. Thanks Sri On Fri, May 22, 2015 at 2:00 AM, Pedro Alves pal...@redhat.com wrote: On 05/21/2015 11:02 PM, Sriraman Tallam wrote: On Thu, May 21, 2015 at 2:51 PM, Pedro Alves

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 28, 2015 at 11:42 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote: I have attached a patch that adds the new attribute noplt. Please review. * config/i386/i386.c (avoid_plt_to_call): New function

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 28, 2015 at 2:52 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, May 28, 2015 at 2:01 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam tmsri...@google.com wrote

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Fri, May 22, 2015 at 2:00 AM, Pedro Alves pal...@redhat.com wrote: On 05/21/2015 11:02 PM, Sriraman Tallam wrote: On Thu, May 21, 2015 at 2:51 PM, Pedro Alves pal...@redhat.com wrote: On 05/21/2015 10:12 PM, Sriraman Tallam wrote: My original proposal, for x86_64 only, was to add -fno-plt

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam tmsri...@google.com wrote: On Sun, May 10, 2015, 8:19 AM H.J. Lu hjl.to...@gmail.com wrote: On Sat, May 9, 2015 at 9:34 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon, May 4, 2015 at 7:45 AM, Michael Matz m...@suse.de wrote: Hi, On Thu, 30

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 21, 2015 at 2:12 PM, Sriraman Tallam tmsri...@google.com wrote: On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam tmsri...@google.com wrote: On Sun, May 10, 2015, 8:19 AM H.J. Lu hjl.to...@gmail.com wrote: On Sat, May 9, 2015 at 9:34 AM, H.J. Lu hjl.to...@gmail.com wrote: On Mon

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, May 21, 2015 at 2:51 PM, Pedro Alves pal...@redhat.com wrote: On 05/21/2015 10:12 PM, Sriraman Tallam wrote: My original proposal, for x86_64 only, was to add -fno-plt=function-name. This lets the user decide for which functions PLT must be avoided. Let the compiler always generate

[RFC] COMDAT Safe Module Level Multi versioning

We have the following problem with selectively compiling modules with -misa options and I have provided a solution to solve this. I would like to hear what you think. Multi versioning at module granularity is done by compiling a subset of modules with advanced ISA instructions, supported on

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, May 19, 2015 at 2:39 AM, Richard Biener richard.guent...@gmail.com wrote: On Tue, May 19, 2015 at 8:16 AM, Sriraman Tallam tmsri...@google.com wrote: We have the following problem with selectively compiling modules with -misa options and I have provided a solution to solve this. I

Re: [RFC] COMDAT Safe Module Level Multi versioning

On Tue, May 19, 2015 at 10:22 AM, Yury Gribov y.gri...@samsung.com wrote: On 05/19/2015 09:16 AM, Sriraman Tallam wrote: We have the following problem with selectively compiling modules with -misa options and I have provided a solution to solve this. I would like to hear what you think

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Fri, May 1, 2015 at 8:01 AM, Andi Kleen a...@firstfloor.org wrote: Sriraman Tallam tmsri...@google.com writes: This comes with caveats. This cannot be generally done for all functions marked extern as it is impossible for the compiler to say if a function is truly extern (defined

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

wrote: On Fri, May 1, 2015 at 8:01 AM, Andi Kleen a...@firstfloor.org wrote: Sriraman Tallam tmsri...@google.com writes: This comes with caveats. This cannot be generally done for all functions marked extern as it is impossible for the compiler to say if a function is truly extern (defined

Re: [RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

On Thu, Apr 30, 2015 at 8:21 PM, Alan Modra amo...@gmail.com wrote: On Thu, Apr 30, 2015 at 05:31:30PM -0700, Sriraman Tallam wrote: This comes with caveats. This cannot be generally done for all functions marked extern as it is impossible for the compiler to say if a function is truly

[RFC][PATCH][X86_64] Eliminate PLT stubs for specified external functions via -fno-plt=

Hi, We noticed that one of our benchmarks sped-up by ~1% when we eliminated PLT stubs for some of the hot external library functions like memcmp, pow. The win was from better icache and itlb performance. The main reason was that the PLT stubs had no spatial locality with the call-sites. I have

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote: On 02/05/2015 11:01 AM, H.J. Lu wrote: Can you elaborate why it depends on COPY relocation? There is no COPY relocation on x86-64. Ho hum, we appear to have switched topics mid-thread. I agree that we cannot override

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Thu, Feb 5, 2015 at 2:23 PM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam tmsri...@google.com wrote: On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson r...@redhat.com wrote: On 02/05/2015 11:01 AM, H.J. Lu wrote: Can you elaborate why it depends

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu hjl.to...@gmail.com wrote: On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote: So we aren't SYMBOL_REF_EXTERNAL_P nor SYMBOL_REF_LOCAL_P. What do we reference? That is

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote: Common symbol should be resolved locally for PIE. binds_local_p yes, binds_to_current_def_p no.

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam tmsri...@google.com wrote: On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Feb

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

+davidxl +ccoutant On Tue, Feb 3, 2015 at 11:25 AM, Sriraman Tallam tmsri...@google.com wrote: On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Thu, Dec 4, 2014 at 8:46 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak ubiz...@gmail.com wrote: On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu hjl.to...@gmail.com wrote: It would probably help reviewers if you pointed to actual path submission [1], which

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote: This was the original patch to i386.c to let global accesses take advantage of copy relocations and avoid the GOT. @@ -13113,7 +13113,11

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Tue, Feb 3, 2015 at 1:29 PM, H.J. Lu hjl.to...@gmail.com wrote: On Tue, Feb 3, 2015 at 1:20 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Feb 3, 2015 at 11:36 AM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Feb 03, 2015 at 11:25:38AM -0800, Sriraman Tallam wrote

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Mon, Nov 10, 2014 at 3:22 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Fri, Sep 19, 2014 at 2:11 PM

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote: Hi Richard, I also ran the gcc testsuite

Re: [PATCH v2, i386]: Fix PR 63538, With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

On Tue, Nov 4, 2014 at 10:47 AM, Uros Bizjak ubiz...@gmail.com wrote: On Tue, Nov 4, 2014 at 10:46 AM, Uros Bizjak ubiz...@gmail.com wrote: Following patch fixes PR 63538, where the data in the large data section was accessed through 32bit address. The patch unifies places where large data

[Google/gcc-4_9][PATCH][target/x86_64] PR 63538

Hi, This patch is under review for trunk GCC : https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html. In the mean time, is this ok for google/gcc-4_9 branch? Without this, -mcmodel=medium is unusable if .lrodata goes beyond the 2G boundary. Thanks Sri Index:

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

the TREE_CODE check to do the right thing so this seems unnecessary buggy here. Thanks Sri David On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam tmsri...@google.com wrote: Hi, This patch is under review for trunk GCC : https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

other case where the constant goes into rodata but is not accessed via a VAR_DECL. Also note that TREE_STATIC (decl) is true for STRING_CST. Thanks Sri David On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li davi

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski pins...@gmail.com wrote: On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li davi...@google.com wrote: Why removing the tree_code check? The actual problem happens

Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538

On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li davi...@google.com wrote: On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski pins...@gmail.com wrote: On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam tmsri

[PATCH][target/x86_64] PR 63538

Hi, I have attached patch for bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538 Please review. Thanks Sri With -mcmodel=medium, .lrodata accesses must use far address. Here the check for TREE_CODE(decl) == VAR_DECL in function ix86_encode_section_info is removed as this does not

Re: [google/gcc-4_9] Add gcc driver option -no-pie

On Mon, Oct 6, 2014 at 4:19 PM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers jos...@codesourcery.com wrote: If adding a new option, you need to document it in invoke.texi. Patch updated. Is this alright for google/gcc-4_9? Sri Thanks Sri

Re: [google/gcc-4_9] Add gcc driver option -no-pie

On Thu, Oct 9, 2014 at 3:34 PM, Cary Coutant ccout...@google.com wrote: If adding a new option, you need to document it in invoke.texi. Patch updated. Is this alright for google/gcc-4_9? +no-pie +Driver RejectNegative Negative(pie) +Create a position dependent executable I'd suggest

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote: Hi Richard, I also ran the gcc testsuite with RUNTESTFLAGS=--tool_opts=-mcopyrelocs to check for issues. The only test

[google/gcc-4_9] Add gcc driver option -no-pie

Hi, A build tool we are using adds -pie by default and I am adding -no-pie to override this when necessary. Is this patch alright? Would this be suitable for trunk? Thanks Sri Add a negative for option -pie: -no-pie builds a position dependent executable. Note that -no-pie also negates a

Re: [google/gcc-4_9] Add gcc driver option -no-pie

On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers jos...@codesourcery.com wrote: If adding a new option, you need to document it in invoke.texi. Patch updated. Thanks Sri -- Joseph S. Myers jos...@codesourcery.com Add a negative for option -pie: -no-pie builds a position dependent

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam tmsri...@google.com wrote: Hi Richard, I also ran the gcc testsuite with RUNTESTFLAGS=--tool_opts=-mcopyrelocs to check for issues. The only test that failed was g++.dg/tsan/default_options.C. It uses -fpie -pie and BFD ld to link

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

with gold to make the test pass. Could you please take another look at this patch? Thanks Sri On Mon, Sep 8, 2014 at 3:19 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson r...@redhat.com wrote: On 06/20/2014 05:17 PM, Sriraman Tallam wrote: Index

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

On Tue, Sep 2, 2014 at 1:40 PM, Richard Henderson r...@redhat.com wrote: On 06/20/2014 05:17 PM, Sriraman Tallam wrote: Index: config/i386/i386.c === --- config/i386/i386.c(revision 211826) +++ config/i386/i386.c

Re: [PATCH] C++ thunk section names

Ping. On Wed, Aug 6, 2014 at 2:42 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, Just wondering if you got a chance to look at this? Sri On Tue, Jul 8, 2014 at 10:45 AM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam tmsri...@google.com

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Fri, Jul 11, 2014 at 10:42 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam tmsri...@google.com wrote: Hi Uros, Could you please review this patch? Thanks Sri On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam tmsri

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam tmsri...@google.com wrote: Hi Uros, Could you please review this patch? Thanks Sri On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam tmsri...@google.com wrote: Patch Updated. Sri On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam

Re: [PATCH] C++ thunk section names

back in now. Jan Thanks, David On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam tmsri...@google.com wrote: Hi Honza, Could you review this patch when you find time? Thanks Sri On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam tmsri...@google.com wrote: Ping

Re: [PATCH] C++ thunk section names

On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam tmsri...@google.com wrote: On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka hubi...@ucw.cz wrote: Hello, I apologize for taking so long to get into this patch. I ad busy time (wedding and teaching), should be back in regular schedule now. Sri

[PATCH][target/i386] PR 61599

Hi, I have attached a patch for this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599. Is this alright? Thanks Sri Patch to fix PR 61599: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599 Function int_size_in_bytes returns -1 in as the size in cases where the size of the type can

Re: [PATCH] C++ thunk section names

Hi Honza, Could you review this patch when you find time? Thanks Sri On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Hi Uros, Could you please review this patch? Thanks Sri On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam tmsri...@google.com wrote: Patch Updated. Sri On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Patch Updated. Sri On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote: Optimize access to globals

Re: [PATCH] C++ thunk section names

Ping. On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Wed, Feb 5, 2014 at 4:31 PM

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote: Optimize access to globals with -fpie, x86_64 only: Currently, with -fPIE/-fpie, GCC accesses globals that are extern

Re: [PATCH] C++ thunk section names

Ping. On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I would like this patch reviewed

Re: [google gcc-4_8][x86_64]Optimize access to globals in -fpie -pie builds with copy relocations

, May 22, 2014 at 4:36 PM, Sriraman Tallam tmsri...@google.com wrote: This patch is pending review for trunk. Please see if this is ok to commit to google/gcc-4_8 branch. Please see this for more details: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html +mld-pie-copyrelocs +Target Report

[google gcc-4_8][x86_64]Optimize access to globals in -fpie -pie builds with copy relocations

This patch is pending review for trunk. Please see if this is ok to commit to google/gcc-4_8 branch. Please see this for more details: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01215.html Patch attached. Thanks Sri Index: config/i386/i386.c

Re: [PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Ping. On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam tmsri...@google.com wrote: Optimize access to globals with -fpie, x86_64 only: Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module using the GOT. This is two instructions, one to get the address

Re: [PATCH] C++ thunk section names

Ping. On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam tmsri...@google.com wrote: Ping. On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I would like this patch reviewed and considered for commit when Stage 1 is active again. Patch Description: A C

[PATCH x86_64] Optimize access to globals in -fpie -pie builds with copy relocations

Optimize access to globals with -fpie, x86_64 only: Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module using the GOT. This is two instructions, one to get the address of the global from the GOT and the other to get the value. If it turns out that the global gets

Re: [PATCH] C++ thunk section names

Ping. On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, I would like this patch reviewed and considered for commit when Stage 1 is active again. Patch Description: A C++ thunk's section name is set to be the same as the original function's section name

Re: [google][gcc-4_8][patch]Handle Split functions in the Function Reordering Plugin

On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson tejohn...@google.com wrote: On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam tmsri...@google.com wrote: Hi Teresa, I have attached a patch to recognize and reorder split functions in the function reordering plugin. Please review. Thanks

Re: [google][gcc-4_8][patch]Handle Split functions in the Function Reordering Plugin

On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson tejohn...@google.com wrote: On Feb 11, 2014 2:37 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Feb 11, 2014 at 1:32 PM, Teresa Johnson tejohn...@google.com wrote: On Mon, Feb 10, 2014 at 7:15 PM, Sriraman Tallam tmsri...@google.com

Re: [google][gcc-4_8][patch]Handle Split functions in the Function Reordering Plugin

On Tue, Feb 11, 2014 at 4:39 PM, Teresa Johnson tejohn...@google.com wrote: On Tue, Feb 11, 2014 at 4:32 PM, Sriraman Tallam tmsri...@google.com wrote: On Tue, Feb 11, 2014 at 3:29 PM, Teresa Johnson tejohn...@google.com wrote: On Feb 11, 2014 2:37 PM, Sriraman Tallam tmsri...@google.com wrote

[google][gcc-4_8][patch]Handle Split functions in the Function Reordering Plugin

Hi Teresa, I have attached a patch to recognize and reorder split functions in the function reordering plugin. Please review. Thanks Sri This enhances the linker plugin to reorder functions that are split when using -freorder-blocks-and-partition. Index:

Re: [google gcc-4_8][patch] Thunk section names

Patch attached. On Thu, Feb 6, 2014 at 2:18 PM, Sriraman Tallam tmsri...@google.com wrote: I sent the following patch for review for trunk commit here. Details here: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00328.html This is important for function layout for the following reason

  1   2   3   4   >