On Fri, Oct 5, 2012 at 10:43 AM, Jason Merrill wrote:
> On 08/24/2012 08:34 PM, Sriraman Tallam wrote:
>>
>> + /* If the address of a multiversioned function dispatcher is taken,
>> + generate the body to dispatch the right function at run-time. This
>>
>> +
On Fri, Oct 5, 2012 at 3:50 PM, Jason Merrill wrote:
> On 10/05/2012 05:57 PM, Sriraman Tallam wrote:
>>
>> In general, the dispatcher is always necessary since it is not known
>> what function version will be called at compile time. This is true
>> whether it is a
On Fri, Oct 26, 2012 at 9:07 AM, Xinliang David Li wrote:
> On Fri, Oct 26, 2012 at 8:54 AM, Jan Hubicka wrote:
>> Hi,
>> sorry for jumping in late, for too long I did not had chnce to look at my
>> TODO.
>> I have two comments...
>>> Index: gcc/cgraphbuild.c
>>>
On Mon, Oct 29, 2012 at 5:55 AM, Jan Hubicka wrote:
>> Index: gcc/cgraph.c
>> ===
>> --- gcc/cgraph.c (revision 192623)
>> +++ gcc/cgraph.c (working copy)
>> @@ -132,6 +132,74 @@ static GTY(()) struct cgraph_edge *free_edges
Hi Jakub,
My function multiversioning patch is being reviewed and I hope to
get this in by Nov. 5.
Thanks,
-Sri.
On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek wrote:
> Status
> ==
>
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have st
On Tue, Oct 30, 2012 at 12:10 PM, Jason Merrill wrote:
> On 10/27/2012 09:16 PM, Sriraman Tallam wrote:
>>
>> + /* See if there's a match. For functions that are
>> multi-versioned,
>> +all the versions match. */
>> if (same_
Ping.
On Mon, Oct 7, 2013 at 1:27 PM, Sriraman Tallam wrote:
> I have updated the patch with one more test.
>
> Thanks
> Sri
>
> On Thu, Oct 3, 2013 at 5:02 PM, Sriraman Tallam wrote:
>> On Mon, Sep 23, 2013 at 4:09 AM, Richard Biener
>> wrote:
>>> On
On Sat, Oct 12, 2013 at 12:10 AM, Uros Bizjak wrote:
> On Sat, Oct 12, 2013 at 2:16 AM, Sriraman Tallam wrote:
>
>> Ping.
>
>>>>> This looks nice. I suppose you grepped for effected targets and rs6000
>>>>> was the only one besides i386.
>>&
On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra wrote:
> On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
>> I committed this patch after making the above change.
>
> /src/gcc-virgin/gcc/config/rs6000/rs6000.c: At global scope:
> /src/gcc-virgin/gcc/config/rs6000
On Wed, Oct 16, 2013 at 4:13 PM, Michael Meissner
wrote:
> On Wed, Oct 16, 2013 at 02:34:56PM -0700, Sriraman Tallam wrote:
>> On Tue, Oct 15, 2013 at 10:54 PM, Alan Modra wrote:
>> > On Tue, Oct 15, 2013 at 02:45:23PM -0700, Sriraman Tallam wrote:
>> >> I committ
On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
> On Wed, Oct 16, 2013 at 7:23 PM, Sriraman Tallam wrote:
>
>> I was unable to build a native powerpc compiler. I checked for
>> build_target_node and build_optimization_node throughout and changed
>> rs6000 because
On Thu, Oct 17, 2013 at 9:28 AM, Steve Ellcey wrote:
> On Thu, 2013-10-17 at 06:03 -0700, Diego Novillo wrote:
>> On Wed, Oct 16, 2013 at 6:06 PM, David Edelsohn wrote:
>>
>> > How is Google going to change its patch commit policies to ensure that
>> > this does not happen again?
>>
>> There is n
00_vector_align[];
> #define MASK_PROTOTYPE OPTION_MASK_PROTOTYPE
> #endif
>
> -/* Explicit ISA options that were set. */
> -#define rs6000_isa_flags_explicit global_options_set.x_rs6000_isa_flags
> -
> /* For power systems, we want to enable Altivec and VS
On Thu, Oct 17, 2013 at 10:49 AM, Jan-Benedict Glaw wrote:
> On Thu, 2013-10-17 10:23:27 -0700, Sriraman Tallam
> wrote:
> [...]
>> I would need the help of target maintainers to fix it this way since
>> it touches every target and it would take time for me to build and
On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek wrote:
> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>> > I would need the help of target maintainers to fix it this way since
>> >
On Thu, Oct 17, 2013 at 12:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 11:48 AM, Jakub Jelinek wrote:
>> On Thu, Oct 17, 2013 at 02:22:57PM -0400, Michael Meissner wrote:
>>> On Thu, Oct 17, 2013 at 10:23:27AM -0700, Sriraman Tallam wrote:
>>> > I
On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>>> You probably want to do something similar to what I did in the powerpc.
>>
>> I would need the help of target maintainers to fix it this way since
>> it tou
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek wrote:
> On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
>> I checked my build again for these tests and they all pass.
>
> Even on x86_64-linux I can reproduce all of those with
> -m32 -mno-sse.
Ok, I never te
On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>>>> You probably want to do something similar to what I did in the powerpc.
>>>
>>> I wo
On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
>> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>>> On Oct 17, 2013, at 10:23 AM, Sriraman Tallam wrote:
>>>>> You probably want to do somet
On Thu, Oct 17, 2013 at 8:37 PM, Mike Stump wrote:
> On Oct 17, 2013, at 7:47 PM, Sriraman Tallam wrote:
>> I can build cross-compile on 32/33 targets. I cannot build
>> nios2-unknown-elf alone, I get "*** Configuration nios2-unknown-elf
>> not supported" error.
On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres wrote:
> Sriraman,
>
> The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
> on targets for which -msse is the default (see
> http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01365.html or
> http://gcc.gnu.org/ml/gcc-testre
On Fri, Oct 18, 2013 at 10:27 AM, Sriraman Tallam wrote:
> On Fri, Oct 18, 2013 at 3:03 AM, Dominique Dhumieres
> wrote:
>> Sriraman,
>>
>> The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
>> on targets for which -msse is the default (se
On Thu, Oct 17, 2013 at 7:47 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 4:51 PM, Sriraman Tallam wrote:
>> On Thu, Oct 17, 2013 at 3:08 PM, Sriraman Tallam wrote:
>>> On Thu, Oct 17, 2013 at 1:23 PM, Mike Stump wrote:
>>>> On Oct 17, 2013, at 10
On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek wrote:
> On Thu, Oct 17, 2013 at 12:30:46PM -0700, Sriraman Tallam wrote:
>> I checked my build again for these tests and they all pass.
>
> Even on x86_64-linux I can reproduce all of those with
> -m32 -mno-sse.
Figured out why th
->...)
(ix86_valid_target_attribute_tree):
Change TARGET_64BIT to TARGET_64BIT_P (opts->...)
Change TARGET_SSE to TARGET_SSE_P (opts->...)
Thanks
Sri
On Fri, Oct 18, 2013 at 7:10 PM, Sriraman Tallam wrote:
> On Thu, Oct 17, 2013 at 3:10 PM, Jakub Jelinek wrote:
>> On Thu, Oct 17, 2013 at 12:30:46
Hi Honza,
It looks like cgraph_fnver_htab defined in cgraph.c is not added
to gc root in gt-cgraph.h. This patch fixes it.
* cgraph.c (cgraph_fnver_htab): Move GTY((...)) to be before htab_t.
Change param_is to use
the struct and not the pointer to the struct.
Index: gcc/cgraph.c
===
Google ref b/11631232
With AutoFDO, the .gnu.callgraph sections are not emitted with option
-freorder-functions=callgraph. This simple patch fixes it.
Index: final.c
===
--- final.c (revision 205418)
+++ final.c (working copy)
@@ -44
On Thu, Nov 28, 2013 at 9:36 PM, Bernd Edlinger
wrote:
> Hi,
>
> On Wed, 27 Nov 2013 19:49:39, Uros Bizjak wrote:
>>
>> On Mon, Nov 25, 2013 at 10:08 PM, Sriraman Tallam
>> wrote:
>>
>>> I have attached a patch to fix this bug :
>>>
&g
Hi,
I have attached a patch to fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390. Please review.
Here is the problem. GCC adds target-specific builtins on demand. The
FMA target-specific builtin __builtin_ia32_vfmaddpd gets added via
this declaration:
void fun() __attribute__((target("fm
Patch updated with two more tests to check if the vfmadd insn is being
produced when possible.
Thanks
Sri
On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam wrote:
> Hi,
>
> I have attached a patch to fix
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59390. Please review.
>
Thanks
>>>> Sri
>>>>
>>>> On Fri, Dec 6, 2013 at 11:12 AM, Sriraman Tallam
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I have attached a patch to fix
>>>>> http://gcc.gnu.org/bugzilla/show_bug.cgi
On Fri, Dec 13, 2013 at 5:06 AM, H.J. Lu wrote:
> On Mon, Dec 2, 2013 at 6:46 PM, Sriraman Tallam wrote:
>> On Thu, Nov 28, 2013 at 9:36 PM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> On Wed, 27 Nov 2013 19:49:39, Uros Bizjak wrote:
>>>>
On Fri, Apr 17, 2015 at 5:36 AM, H.J. Lu wrote:
> On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek 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 library for that.
>>> > So, IMH
On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam wrote:
> On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li wrote:
>>>
>>> Hm. But which options are unsafe? Also wouldn't it be better to simply
>>> _not_ have unsafe options produce comdats but always make l
On Wed, Sep 9, 2015 at 4:01 PM, Sriraman Tallam wrote:
> On Wed, Sep 2, 2015 at 4:32 PM, Sriraman Tallam wrote:
>>
>> On Tue, Aug 18, 2015 at 9:46 PM, Cary Coutant wrote:
>> >> Thanks, will make those changes. Do you recommend a different name
>> >> for
Hi,
Just wondering if you got a chance to look at this?
Sri
On Tue, Jul 8, 2014 at 10:45 AM, Sriraman Tallam wrote:
> On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
>> On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka wrote:
>>> Hello,
>>> I apologize for taki
Ping.
On Wed, Aug 6, 2014 at 2:42 PM, Sriraman Tallam 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 wrote:
>> On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
>>>
Ping.
On Fri, Jul 11, 2014 at 10:42 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, Jun 26, 2014 at 10:54 AM, Sriraman Tallam wrote:
>> Hi Uros,
>>
>>Could you please review this patch?
>>
>> Thanks
>> Sri
>>
>> On Fri, Jun 20, 2
On Tue, Nov 12, 2013 at 7:54 AM, Steven Bosscher wrote:
> On Tue, Nov 12, 2013 at 3:49 PM, Teresa Johnson wrote:
>>> Is there a format for compiler-defined labels that would not be able
>>> to clash with other user-generated labels?
>>
>> My understanding is that the "." in the generated name ensu
On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote:
> There was something wrong with Bernd's address, retrying.
>
>>> Currently on trunk the option -mpreferred-stack-boundary does not work
>>> together with #pragma GCC target("sse") or __attribute__((target("sse"))).
>>>
>>> There is already a te
On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger
wrote:
> Hi,
>
>
> On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam wrote:
>>
>> On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote:
>>> There was something wrong with Bernd's address, retrying.
>>>
On Tue, Nov 12, 2013 at 5:17 PM, Sriraman Tallam wrote:
> On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>>
>> On Tue, 12 Nov 2013 10:30:16, Sriraman Tallam wrote:
>>>
>>> On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wr
On Tue, Nov 12, 2013 at 10:10 AM, Cary Coutant wrote:
Is there a format for compiler-defined labels that would not be able
to clash with other user-generated labels?
>>>
>>> My understanding is that the "." in the generated name ensures that it
>>> will not clash with user-generated labe
On Wed, Nov 13, 2013 at 5:12 PM, Bernd Edlinger
wrote:
> On Tue, 12 Nov 2013 17:50:27, Sriraman Tallam wrote:
>>
>> On Tue, Nov 12, 2013 at 5:17 PM, Sriraman Tallam wrote:
>>> On Tue, Nov 12, 2013 at 2:53 PM, Bernd Edlinger
>>> wrote:
>>>> Hi
On Fri, Nov 15, 2013 at 1:58 AM, Bernd Edlinger
wrote:
> On Fri, 15 Nov 2013 10:09:02, Uros Bizjak wrote:
>>
>> On Fri, Nov 15, 2013 at 4:54 AM, Sriraman Tallam wrote:
>>
>>>>>>>>>>> Currently on trunk the option -mpreferred-stack-boundar
On Wed, Nov 13, 2013 at 10:00 AM, Sriraman Tallam wrote:
> On Tue, Nov 12, 2013 at 10:10 AM, Cary Coutant wrote:
>>>>> Is there a format for compiler-defined labels that would not be able
>>>>> to clash with other user-generated labels?
>>>>
>>&
On Mon, Nov 18, 2013 at 12:16 PM, Steven Bosscher wrote:
> On Mon, Nov 18, 2013 at 9:01 PM, Sriraman Tallam wrote:
>>> I have modified my original patch to use clone_function_name to
>>> generate the cold part label and attached it.
>>
>> Is this patch fine
On Tue, Nov 19, 2013 at 5:31 AM, Yuri Rumyantsev wrote:
> Hi All,
>
> We found out that compiler configured with '-fpmath=sse' option does
> not generate scalar floating-point instructions present in the SSE
> instruction set for generic32 that leads to performance degradation
> for Fortran benchm
Hi,
Currently, tree unrolling pass(cunroll) does not allow any code
size growth in O2 mode. Code size growth is permitted only if O3 or
funroll-loops/fpeel-loops is used. I have created a patch to allow
partial code size increase in O2 mode. With funroll-loops the maximum
allowed code growth
Hi,
I have attached a patch to fix this bug :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
A similar problem was also reported here:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01050.html
Recently, ix86_valid_target_attribute_tree in config/i386/i386.c was
refactored to not depend
Ping.
On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam wrote:
> Ping.
>
> On Fri, Sep 19, 2014 at 2:11 PM, Sriraman Tallam wrote:
>> Hi Richard,
>>
>> I also ran the gcc testsuite with
>> RUNTESTFLAGS="--tool_opts=-mcopyrelocs" to check for issues. T
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 pri
On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers 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 executable.
Note that -no-pie
On Mon, Oct 6, 2014 at 4:19 PM, Sriraman Tallam wrote:
> On Mon, Oct 6, 2014 at 3:22 PM, Joseph S. Myers
> 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
&g
On Thu, Oct 9, 2014 at 3:34 PM, Cary Coutant 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 add
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 handl
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: testsuite/gcc.dg/pr63538.c
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 wrote:
>> Hi,
>>
>>This patch is under review for trunk GCC :
>> https://gcc.gnu.org/ml/gcc-patches/2014-
er 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 wrote:
>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David
On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote:
> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote:
>> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li
>> wrote:
>>> Why removing the tree_code check?
>>
>> The actual problem happens bec
On Mon, Oct 20, 2014 at 12:59 PM, Xinliang David Li wrote:
> On Mon, Oct 20, 2014 at 11:59 AM, Sriraman Tallam wrote:
>> On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote:
>>> On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam
>>> wrote:
>>>> On
Ping.
On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam wrote:
>> Optimize access to globals with -fpie, x86_64 only:
>>
>> Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the
Ping.
On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam wrote:
> Ping.
>
> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam wrote:
>>> Hi,
>>>
>>> I would like this p
Ping.
On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam
>> wrote:
>>> Ping.
>>>
>>> On
Patch Updated.
Sri
On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, May 19, 2014 at 11:11 AM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Thu, May 15, 2014 at 11:34 AM, Sriraman Tallam
>> wrote:
>>> Optimize access to globals
Hi Honza,
Could you review this patch when you find time?
Thanks
Sri
On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam
>
Hi Uros,
Could you please review this patch?
Thanks
Sri
On Fri, Jun 20, 2014 at 5:17 PM, Sriraman Tallam wrote:
> Patch Updated.
>
> Sri
>
> On Mon, Jun 9, 2014 at 3:55 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, May 19, 2014 at 11:11 AM, Sri
We have the following problem with selectively compiling modules with
-m 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 later
ge
On Tue, May 19, 2015 at 2:39 AM, Richard Biener
wrote:
> On Tue, May 19, 2015 at 8:16 AM, Sriraman Tallam wrote:
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like t
On Tue, May 19, 2015 at 10:22 AM, Yury Gribov wrote:
> On 05/19/2015 09:16 AM, Sriraman Tallam wrote:
>>
>> We have the following problem with selectively compiling modules with
>> -m options and I have provided a solution to solve this. I would
>> like to hear
On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>
> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>
> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>> On Mon, May 4, 2015 at 7:45 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Thu, 30 Apr 201
On Thu, May 21, 2015 at 2:12 PM, Sriraman Tallam wrote:
> On Sun, May 10, 2015 at 10:01 AM, Sriraman Tallam wrote:
>>
>> On Sun, May 10, 2015, 8:19 AM H.J. Lu wrote:
>>
>> On Sat, May 9, 2015 at 9:34 AM, H.J. Lu wrote:
>>> On Mon, May 4, 2015 at 7
On Thu, May 21, 2015 at 2:51 PM, Pedro Alves wrote:
> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>>
>> My original proposal, for x86_64 only, was to add
>> -fno-plt=. This lets the user decide for which
>> functions PLT must be avoided. Let the compiler always g
On Fri, May 22, 2015 at 2:00 AM, Pedro Alves wrote:
> On 05/21/2015 11:02 PM, Sriraman Tallam wrote:
>> On Thu, May 21, 2015 at 2:51 PM, Pedro Alves wrote:
>>> On 05/21/2015 10:12 PM, Sriraman Tallam wrote:
>>>>
>>>> My original proposal, for x86_64 only
ibute "noplt".
* doc/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 wrote:
> On 05/21/2015 11:02 PM, Sriraman Tallam wrote:
>
On Thu, May 28, 2015 at 11:42 AM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam wrote:
>> I have attached a patch that adds the new attribute "noplt". Please review.
>>
>> * config/i386/i386.c (avoid_plt_to_call): New function.
>> (ix86
On Thu, May 28, 2015 at 12:05 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 11:42 AM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 11:34 AM, Sriraman Tallam
>>> wrote:
>>>> I have attached a p
On Thu, May 28, 2015 at 2:01 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 12:05 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 11:50 AM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at
On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 2:01 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 1:54 PM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at 12:0
On Thu, May 28, 2015 at 5:05 PM, H.J. Lu wrote:
> On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam wrote:
>> On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
>>> On Thu, May 28, 2015 at 2:27 PM, Sriraman Tallam
>>> wrote:
>>>> On Thu, May 28, 2015 at 2:0
Hi HJ,
Is this ok to commit?
Thanks
Sri
On Thu, May 28, 2015 at 11:03 PM, Sriraman Tallam wrote:
> On Thu, May 28, 2015 at 5:05 PM, H.J. Lu wrote:
>> On Thu, May 28, 2015 at 4:54 PM, Sriraman Tallam wrote:
>>> On Thu, May 28, 2015 at 2:52 PM, H.J. Lu wrote:
>>>>
+Uros
On Fri, May 29, 2015 at 10:25 AM, H.J. Lu wrote:
> On Fri, May 29, 2015 at 10:20 AM, Sriraman Tallam wrote:
>> Hi HJ,
>>
>> Is this ok to commit?
>>
>
> Looks good to me. But I can't approve it.
>
> --
> H.J.
On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka 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 "nopl
Made one more change and New patch attached.
Thanks
Sri
On Fri, May 29, 2015 at 2:37 PM, Sriraman Tallam wrote:
> On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka wrote:
>>> * config/i386/i386.c (avoid_plt_to_call): New function.
>>> (ix86_output_call_insn): Gener
On Fri, May 29, 2015 at 3:24 PM, Ramana Radhakrishnan
wrote:
>
>
> On Friday, 29 May 2015, Sriraman Tallam wrote:
>>
>> On Fri, May 29, 2015 at 12:35 PM, Jan Hubicka wrote:
>> >> * config/i386/i386.c (avoid_plt_to_call): New function.
>> >>
On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan
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 backend.
>>> Also i
On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan
wrote:
> On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 1:24 AM, Ramana Radhakrishnan
>> wrote:
>>>
>>>>> Why isn't it just an indirect call in the cases that woul
On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan
wrote:
> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 11:41 AM, Ramana Radhakrishnan
>> wrote:
>>> On Mon, Jun 1, 2015 at 7:01 PM, Sriraman Tallam wrote:
>>>> On
On Tue, Jun 2, 2015 at 12:32 PM, Bernhard Reutner-Fischer
wrote:
> On June 2, 2015 8:15:42 PM GMT+02:00, Sriraman Tallam
> wrote:
> []
>
>>I have now modified this patch.
>>
>>This patch does two things:
>>
>>1) Adds new generic function attribute "
On Tue, Jun 2, 2015 at 1:56 PM, Ramana Radhakrishnan
wrote:
> On Tue, Jun 2, 2015 at 7:15 PM, Sriraman Tallam wrote:
>> On Mon, Jun 1, 2015 at 1:33 PM, Ramana Radhakrishnan
>> wrote:
>>> On Mon, Jun 1, 2015 at 7:55 PM, Sriraman Tallam wrote:
>>>> On
>
> 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
On Wed, Jun 3, 2015 at 1:09 PM, Richard Henderson 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&#x
> 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.
On Thu, Jun 4, 2015 at 10:05 AM, Richard Henderson 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_OF
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 st
On Thu, Apr 30, 2015 at 8:21 PM, Alan Modra 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 func
On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
> Sriraman Tallam 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"
>>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen wrote:
>>>> Sriraman Tallam writes:
>>>>>
>>>>> This comes with caveats. This cannot be generally done for all
>>>>> functions marked extern as it is impossible for the compiler to say i
Ping.
On Mon, Nov 10, 2014 at 3:22 PM, Sriraman Tallam wrote:
> Ping.
>
> On Mon, Oct 6, 2014 at 1:43 PM, Sriraman Tallam wrote:
>> Ping.
>>
>> On Mon, Sep 29, 2014 at 10:57 AM, Sriraman Tallam
>> wrote:
>>> Ping.
>>>
>>> On Fri, S
1 - 100 of 364 matches
Mail list logo
