Ping[3]: [PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

Ping! On Tue, Nov 27, 2012 at 03:32:46PM +0530, Siddhesh Poyarekar wrote: Ping! Siddhesh On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote: Hi, Ping! Siddhesh On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote: Hi, Here's an updated version

Re: PATCH to libstdc++ to use __cxa_thread_atexit_impl if available

Cc'ing Carlos on this so that he's aware of it. Siddhesh Jakub Jelinek ja...@redhat.com wrote: On Sat, Jan 19, 2013 at 12:22:23PM -0500, Jason Merrill wrote: Siddhesh has a patch to implement the thread atexit functionality in glibc in order to integrate better with the dynamic loader and run

Re: [RESEND-2][PATCH] Allow printing of escaped curly braces in assembler directives with operands

On Fri, 20 Jul 2012 22:24:57 -0400 (EDT), Hans-Peter wrote: Sounds like a good idea, but I think you shouldn't limit that to {} but rather introduce \ to escape and cause any next character to be emitted as-is, in particular |. I had dropped the change to escape | thinking it wasn't needed --

[PATCH] Fix assembly dialect handling in asm_fprintf

mentioned above is fixed. Regards, Siddhesh [1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00840.html gcc/ChangeLog: 2012-07-25 Siddhesh Poyarekar siddh...@redhat.com * final.c [ASSEMBLER_DIALECT](do_assembler_dialects): New function to implement assembler dialects

Re: [PATCH] Fix assembly dialect handling in asm_fprintf

On Wed, 25 Jul 2012 08:31:14 -0700, Richard wrote: * gcc.dg/asm-dialect-1.c: New test case. ... except this should go in gcc.target/i386/ without the { target } qualifier. Thanks, here's the updated version. Regards, Siddhesh gcc/ChangeLog: 2012-07-25 Siddhesh Poyarekar siddh

[RESEND-2][PATCH] Allow printing of escaped curly braces in assembler directives with operands

Hi, Resending. I did not get any responses the last two times and I too forgot about it. Can someone please review this? Thanks, Siddhesh Begin forwarded message: Date: Tue, 3 Apr 2012 18:46:53 +0530 From: Siddhesh Poyarekar siddh...@redhat.com To: gcc-patches@gcc.gnu.org Subject: Fw: [PATCH

[PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

Hi, When the location for throw() exception specification is not the same as the function it is written against, it leads gcov to give incorrect results. See bug 50055 for details of the the same. The following patch makes sure that the exception specification block (nothrow or otherwise) is

Re: [PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

information. I think Siddhesh should be covered by the Red Hat assignment (it would help if the patch has been mailed from a redhat.com address to notice that). Thanks! I will keep that in mind for future submissions. -- Siddhesh Poyarekar http://siddhesh.in

[PATCH] Allow printing of escaped curly braces in assembler directives with operands

transformation. The patch does not introduce any regressions. I have tested this with x86_64 and i686 and it works well with both of them. Regards, Siddhesh gcc/ChangeLog: 2012-03-27 Siddhesh Poyarekar siddh...@redhat.com * final.c (output_asm_insn, asm_fprintf): Print curly braces

Fw: [PATCH] Allow printing of escaped curly braces in assembler directives with operands

Hi, ping? -- Siddhesh Begin forwarded message: Date: Tue, 27 Mar 2012 10:51:37 +0530 From: Siddhesh Poyarekar siddh...@redhat.com To: gcc-patches@gcc.gnu.org Subject: [PATCH] Allow printing of escaped curly braces in assembler directives with operands Hi, An assembler directive

[PATCH] Fix array access beyond bounds in test cases

to think that the test case is incorrect. I am not sure what the test case verifies since the array accesses are obviously beyond bounds. Regards, Siddhesh testsuite/ChangeLog: 2012-11-09 Siddhesh Poyarekar siddh...@redhat.com * gcc.dg/Warray-bounds-3.c (bar): Keep array access within

[PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

in the testsuite that I haven't figured out yet. I have tested the patch on x86_64 for C language and the testsuite reports no regressions. In fact, it seems to have fixed a previous failure in gcc.dg/vect/slp-perm-9.c. Regards, Siddhesh ChangeLog: 2012-11-09 Siddhesh Poyarekar siddh...@redhat.com

Re: [PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

On Fri, 9 Nov 2012 17:34:26 +0100, Jan wrote: I don't mind saying that GCC should define cases that the language standards leave undefined. But that does not seem to be what this patch does. I don't see why this is a good idea. It seems to produce a program that is unpredictable in a

Re: [PATCH] Fix array access beyond bounds in test cases

On Fri, 09 Nov 2012 11:57:44 -0700, Jeff wrote: The off-by-one aspects of 31227 ought to be corrected. Ok for the trunk, I don't have write access (not sure if I qualify for it yet with just a couple of trivial patches so far) so I need someone to commit for me. Thanks, Siddhesh

Re: [PATCH] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote: I had reckoned that the behaviour could be reverted to what was before while I figure out a way to get the warning in place for both cases, i.e. with tree-vrp (where max_loop_iterations now causes the loop to be folded away in -O2) and this

[PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

Hi, Here's an updated version of the patch which warns the user if the removing of redundant exits results in an infinite loop. I have added an additional flag in struct loop called external_exits to record if an exit edge is moved outside the loop body. This currently happens in the

[PATCH] Disable libsanitizer if C++ is not being built

Hi, Current HEAD fails build when --enable-languages=c, i.e. C++ is not being built. Attached patch fixes this. Regards, Siddhesh ChangeLog: 2012-11-15 Siddhesh Poyarekar siddh...@redhat.com * configure.ac: Disable libsanitizer if we're not building C++. * configure

Ping: [PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

Hi, Ping! Siddhesh On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote: Hi, Here's an updated version of the patch which warns the user if the removing of redundant exits results in an infinite loop. I have added an additional flag in struct loop called external_exits to record if an

Ping: [PATCH] Disable libsanitizer if C++ is not being built

Hi, Ping! Siddhesh On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote: Hi, Current HEAD fails build when --enable-languages=c, i.e. C++ is not being built. Attached patch fixes this. Regards, Siddhesh ChangeLog: 2012-11-15 Siddhesh Poyarekar siddh...@redhat.com

Ping[2]: [PATCH v2] PR tree-optimization/55079: Don't remove all exits of a loop during loop unroll

Ping! Siddhesh On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote: Hi, Ping! Siddhesh On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote: Hi, Here's an updated version of the patch which warns the user if the removing of redundant exits results

Ping[2]: [PATCH] Disable libsanitizer if C++ is not being built

Ping! Siddhesh On Wed, Nov 21, 2012 at 12:43:10PM +0530, Siddhesh Poyarekar wrote: Hi, Ping! Siddhesh On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote: Hi, Current HEAD fails build when --enable-languages=c, i.e. C++ is not being built. Attached patch fixes

Re: [PATCH] Disable libsanitizer if C++ is not being built

On Tue, Nov 27, 2012 at 11:05:47AM +0100, Jakub Jelinek wrote: On Thu, Nov 15, 2012 at 07:52:21PM +0530, Siddhesh Poyarekar wrote: 2012-11-15 Siddhesh Poyarekar siddh...@redhat.com * configure.ac: Disable libsanitizer if we're not building C++. * configure: Regenerate. Ok

[PING][PATCH v2][aarch64] Add mcpu flag for Qualcomm falkor core

Ping! Siddhesh On 4 November 2016 at 21:17, Siddhesh Poyarekar <siddhesh.poyare...@linaro.org> wrote: > This adds an mcpu option for the upcoming Qualcomm Falkor core. This > is identical to the qdf24xx part that was added earlier and hence > retains the same tuning structur

[PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

Hi, This patch documents the newly added flag in gcc 7 for the upcoming Qualcomm Falkor processor core. Siddhesh Index: htdocs/gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.24

[PATCH] Add mcpu flag for Qualcomm falkor core

This adds an mcpu option for the upcoming Qualcomm Falkor core. This is identical to the qdf24xx part that was added earlier and hence retains the same tuning structure and continues to have the a57 pipeline for now. The part number has also been changed and this patch fixes this for both

Re: [PATCH] Add mcpu flag for Qualcomm falkor core

On 3 November 2016 at 23:08, Andrew Pinski wrote: > This patch no longer applies after the recent changes (starting around > a month ago) to aarch64-cores.def. Please updat the patch for the > recent changes Sorry about that, I'll post an updated patch shortly. Siddhesh

[PATCH v2] Add mcpu flag for Qualcomm falkor core

This adds an mcpu option for the upcoming Qualcomm Falkor core. This is identical to the qdf24xx part that was added earlier and hence retains the same tuning structure and continues to have the a57 pipeline for now. The part number has also been changed and this patch fixes this for both

Re: [PATCH v2] Add mcpu flag for Qualcomm falkor core

On 5 January 2017 at 05:00, Gerald Pfeifer wrote: > In case you are wondering, Siddhesh, Richard was referring > to https://gcc.gnu.org/gcc-7/changes.html and at > https://gcc.gnu.org/about.html you'll find some documentation > on how to go about updating that. I did post a

[PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

Hi, This patch documents the newly added flag in gcc 7 for the upcoming Qualcomm Falkor processor core. Siddhesh Index: htdocs/gcc-7/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.33

Re: [PATCH] [pr#83069] Keep profile_count for bb under real_bb_freq_max

On Friday 24 November 2017 05:36 PM, Siddhesh Poyarekar wrote: > freq_max < 1, i.e. highest frequency among bbs in the function being > higher than real_bb_freq_max means that the bb ends up with a profile > count larger than real_bb_freq_max and then can go all the way up to

[PATCH] [pr#83069] Keep profile_count for bb under real_bb_freq_max

freq_max < 1, i.e. highest frequency among bbs in the function being higher than real_bb_freq_max means that the bb ends up with a profile count larger than real_bb_freq_max and then can go all the way up to and beyond profile_count::max_count. Bootstrapped on aarch64, testsuite in progress.

Re: [PATCH] New option saphira for Qualcomm server part

On 3 November 2017 at 15:50, Richard Earnshaw <richard.earns...@foss.arm.com> wrote: >> 2017-10-27 Siddhesh Poyarekar <siddhesh.poyare...@linaro.org> >> Jim Wilson <jim.wil...@linaro.org> >> >> gcc/ >> *

Re: [PATCH] New option saphira for Qualcomm server part

Ping! Siddhesh On 27 October 2017 at 18:13, Siddhesh Poyarekar <siddh...@gotplt.org> wrote: > From: Siddhesh Poyarekar <siddhesh.poyare...@linaro.org> > > This patch adds an mcpu option for the Qualcomm saphira server part. > Tested on aarch64 and did not find any re

[PATCH] [aarch64] Remove obsolete comment about X30

r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of which this comment about X30 not being marked as call-clobbered is no longer accurate. Siddhesh * config/aarch64/aarch64.h: Remove obsolete comment. --- gcc/config/aarch64/aarch64.h | 9 - 1 file changed, 9

Re: [PATCH][AArch64] Support for LDP/STP of Q-registers

On 06/05/2018 10:02 PM, Kyrill Tkachov wrote: Adding some folks who know more about other CPUs as well. Are you okay with enabling these instructions in AArch64? If you could give this a spin on some benchmarks you care about on your platforms it would be really useful data. Sameera had

Re: [AARCH64] Add support of ARMv8.4 in saphira for Qualcomm server part

On 29 May 2018 at 21:17, James Greenhalgh wrote: > On Tue, May 29, 2018 at 05:01:42AM -0500, Sameera Deshpande wrote: >> Hi! >> >> Please find attached the patch to add support of ARMv8.4 in saphira >> for Qualcomm server part. Tested on aarch64, without any regressions. >> >> Ok for trunk? > >

Re: [PATCH][aarch64] Avoid tag collisions for loads on falkor

On 07/02/2018 03:29 PM, Kyrill Tkachov wrote: Nice! What were the regressions though? Would be nice to adjust the tests to make them more robust so that we have as clean a testsuite as possible. Sure, they're gcc.dg/guality/pr36728-2.c and gcc.target/aarch64/extend.c. The addressing mode

[PATCH][aarch64] Avoid tag collisions for loads on falkor

-02 Siddhesh Poyarekar Kugan Vivekanandarajah * config/aarch64/falkor-tag-collision-avoidance.c: New file. * config.gcc (extra_objs): Build it. * config/aarch64/t-aarch64 (falkor-tag-collision-avoidance.o): Likewise. * config/aarch64/aarch64

Re: [PATCH] [aarch64] Remove obsolete comment about X30

On 06/19/2018 09:11 PM, James Greenhalgh wrote: On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote: r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of which this comment about X30 not being marked as call-clobbered is no longer accurate. Is the second

[PATCH] New option saphira for Qualcomm server part

From: Siddhesh Poyarekar <siddhesh.poyare...@linaro.org> This patch adds an mcpu option for the Qualcomm saphira server part. Tested on aarch64 and did not find any regressions resulting from this patch. Siddhesh 2017-10-27 Siddhesh Poyarekar <siddhesh.poyare...@l

Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

On Wednesday 17 January 2018 08:31 PM, Wilco Dijkstra wrote: > Why is that a bad thing? With the patch as is, the testcase generates: > > .L4: > ldr q0, [x2, x3] > add x5, x1, x3 > add x3, x3, 16 > cmp x3, x4 > str q0, [x5] > bne .L4 >

Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

On Wednesday 17 January 2018 07:07 PM, Wilco Dijkstra wrote: > (finished version this time, somehow Outlook loves to send emails early...) > > Hi, > > In general I think the best way to achieve this would be to use the > existing cost models which are there for exactly this purpose. If > this

Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

On Wednesday 17 January 2018 11:13 PM, Wilco Dijkstra wrote: > Are you saying the same issue exists for all stores with writeback? If so then > your patch would need to address that too. Yes, I'll be posting a separate patch for that because the condition set is slightly different for it. It

Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

ro.org> Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org> Siddhesh Poyarekar <siddh...@sourceware.org> gcc/ * gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type): New member ADDR_QUERY_STR. * gcc/config/aarch64/aar

[PATCH, committed] Add myself to the MAINTAINERS file

From: Siddhesh Poyarekar <siddh...@sourceware.org> * MAINTAINERS (write after approval): Add myself. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@256836 138bc75d-0d04-0410-961f-82ee72b054a4 --- ChangeLog | 4 MAINTAINERS | 1 + 2 files changed, 5 insertions(+) diff

Re: [PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

org> Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org> Siddhesh Poyarekar <siddh...@sourceware.org> gcc/ * gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type): New member ADDR_QUERY_STR. * gcc/config/aarch64/aarch6

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

On Wednesday 24 January 2018 06:29 PM, Siddhesh Poyarekar wrote: >>> +  /* Avoid register indexing for 128-bit stores when the >>> + AARCH64_EXTRA_TUNE_SLOW_REGOFFSET_QUADWORD_STORE option is set.  */ >>> +  if (!optimize_size >>&

[PATCH v3] Disable reg offset in quad-word store for Falkor

% and intspeed by 0.62% in CPU2017, with xalancbmk_s (3.84%) wrf_s (1.46%) and mcf_s (1.62%) being the biggest winners. There were no regressions beyond 0.4%. 2018-xx-xx Jim Wilson <jim.wil...@linaro.org> Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org>

Re: [PING][PATCH v3] Disable reg offset in quad-word store for Falkor

On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote: > So it seems to me using existing cost mechanisms is always preferable, even > if you > currently can't differentiate between loads and stores. Luis is working on address cost adjustments among other things, so I guess the path of

[PING][PATCH v3] Disable reg offset in quad-word store for Falkor

Ping! On Friday 09 February 2018 01:02 PM, Siddhesh Poyarekar wrote: > Hi, > > Here's v3 of the patch to disable register offset addressing mode for > stores of 128-bit values on Falkor because they're very costly. > Following Kyrill's suggestion, I compared the codegen for

Re: [PATCH] c++: Fix spurious fallthrough warning on break

On Tuesday 20 February 2018 03:14 PM, Jakub Jelinek wrote: > On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote: >> The C++ frontend generates a break that results in the fallthrough >> warning misfiring in nested switch blocks where cases in the inner >>

Re: [PATCH] c++: Fix spurious fallthrough warning on break

On Monday 19 February 2018 09:59 PM, Siddhesh Poyarekar wrote: > The C++ frontend generates a break that results in the fallthrough > warning misfiring in nested switch blocks where cases in the inner > switch block return, rendering the break pointless. The fallthrough &g

[PATCH] c++: Fix spurious fallthrough warning on break

The C++ frontend generates a break that results in the fallthrough warning misfiring in nested switch blocks where cases in the inner switch block return, rendering the break pointless. The fallthrough detection in finish_break_stmt does not work either because the condition is encoded as an

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

On Friday 02 February 2018 05:15 AM, Martin Sebor wrote: > PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within > array > > gcc/ChangeLog: > > PR middle-end/84095 > * gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range): New. >

[PATCH] Fix bogus function cast warning for functions with common arg subset

Libraries like gtk/glib[1] and python[2] use functions with common argument subsets to register callbacks. The working idea behind it is to have a flag in the structure (or some other pre-determined method) that specifies how the callback is cast and called. Fix this by not throwing a warning

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

On Friday 23 February 2018 09:20 PM, David Malcolm wrote: > Do we have a PR open for this yet? > > I believe this is an example of where this bit (for the Python case): > https://github.com/imageworks/OpenColorIO/pull/518 There is now: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531

Re: [PATCH] correct -Wrestrict handling of arrays of arrays (PR 84095)

On Friday 23 February 2018 09:22 PM, Martin Sebor wrote: > I see no failures in this test in any of the recently reported > results on any targets except those below: > >   https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01530.html >  

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

On Saturday 24 February 2018 12:01 AM, Richard Biener wrote: > I don't see how the function cast is valid. > > I've argued for void (*) () to/from void (*) (int), etc. In the past and that > was shot down similarly. This looks like exactly the same thing. That should not throw a warning

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote: > Casting the address of a function that takes one or more arguments > to one that takes fewer is unsafe because when the pointer is used > to call the function the extra arguments have indeterminate values. > (This is also why

Re: [PATCH] Fix bogus function cast warning for functions with common arg subset

On Saturday 24 February 2018 03:28 AM, Martin Sebor wrote: > In my mind that would be a perfectly reasonable approach. > A variation on it might be to leave a new warning disabled > in the first release, then include it in -Wextra the next > release, and finally put it in -Wall. > >

[PING 2][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Ping! Siddhesh On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset

Re: [PATCH] [aarch64] Fix falkor pipeline description for dup

On 08/02/2018 04:19 PM, Kyrill Tkachov wrote: Hi Siddhesh, On 02/08/18 11:23, Siddhesh Poyarekar wrote: There was a typo in the pipeline description where DUP was assigned to the vector pipes for quad mode ops when it really only uses the VTOG pipes.  Fixing this does not show any noticeable

[PATCH] [aarch64][v2] Fix falkor pipeline description for dup

There was a typo in the pipeline description where DUP was assigned to the vector pipes for quad mode ops when it really only uses the VTOG pipes. Fixing this does not show any noticeable difference in performance (there's a very small bump of 1.7% in x264 but that's about it) in my tests but is

Re: [PATCH] [aarch64][v2] Fix falkor pipeline description for dup

On 08/03/2018 12:02 AM, James Greenhalgh wrote: On Thu, Aug 02, 2018 at 11:58:37AM -0500, Siddhesh Poyarekar wrote: There was a typo in the pipeline description where DUP was assigned to the vector pipes for quad mode ops when it really only uses the VTOG pipes. Fixing this does not show any

[PATCH] [aarch64] Fix falkor pipeline description for dup

There was a typo in the pipeline description where DUP was assigned to the vector pipes for quad mode ops when it really only uses the VTOG pipes. Fixing this does not show any noticeable difference in performance (there's a very small bump of 1.7% in x264 but that's about it) in my tests but is

[PING][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Hello, Ping! On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide

Re: [PING 3][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

On 08/07/2018 10:30 PM, James Greenhalgh wrote: To help set expectations here. I'm currently only able to dedicate a couple of hours of time to review each week. Tamar's Stack Clash has been taking a big chunk of that time recently as we push it to a final state for trunk. This pass is... large

Re: [PATCH] [AArch64, Falkor] Adjust Falkor's sign extend reg+reg address cost

On 08/01/2018 04:24 AM, James Greenhalgh wrote: OK if this is what is best for your subtarget. I have pushed this on behalf of Luis since he is on holiday. Thanks, Siddhesh

Re: [PATCH] [AArch64, Falkor] Switch to using Falkor-specific vector costs

On 08/01/2018 04:23 AM, James Greenhalgh wrote: On Wed, Jul 25, 2018 at 01:10:34PM -0500, Luis Machado wrote: The adjusted vector costs give Falkor a reasonable boost in performance for FP benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that much. About 0.7% for CPU2017

[PING 3][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Hello, Ping! Siddhesh On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset

[PING 4][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Ping! On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide which

[PING 5][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

Ping! On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote: Hi, This is a rewrite of the tag collision avoidance patch that Kugan had written as a machine reorg pass back in February. The falkor hardware prefetching system uses a combination of the source, destination and offset to decide which

Re: [PATCH] [v2][aarch64] Avoid tag collisions for loads falkor

On 07/13/2018 06:32 PM, Kyrill Tkachov wrote: This looks good to me modulo a couple of minor comments inline. You'll still need an approval from a maintainer. Thanks, I'll send a fixed up version on Monday. +  for (ause= DF_REG_USE_CHAIN (regno); ause; ause = DF_REF_NEXT_REG (ause)) +    {

[PATCH] [v3][aarch64] Avoid tag collisions for loads falkor

that falkor does not support sve Changes from v1: - Fixed up issues pointed out by Kyrill - Avoid renaming R0/V0 since they could be return values - Fixed minor formatting issues. 2018-07-02 Siddhesh Poyarekar Kugan Vivekanandarajah * config/aarch64/falkor-tag-collision

[PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

R0/V0 since they could be return values - Fixed minor formatting issues. 2018-07-02 Siddhesh Poyarekar Kugan Vivekanandarajah * config/aarch64/falkor-tag-collision-avoidance.c: New file. * config.gcc (extra_objs): Build it. * config/aarch64/t-aarch64

Re: [PATCH] [v3][aarch64] Avoid tag collisions for loads falkor

On 07/16/2018 09:59 PM, Kyrill Tkachov wrote: I think this looks ok now. You'll still need a maintainer to approve it though. Thank you for the review Kyrill, but also apologies for wasting your time on it. I just found that the patch breaks a test so I'm currently reviewing it to see

Re: [PING 5][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

On Thursday 30 August 2018 01:28 PM, Siddhesh Poyarekar wrote: On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote: Sorry that this took me so long to get to.  > > The code is outstanding quality, a textbook example of writing an > analysis/optimization pass using m

Re: [PING 5][PATCH] [v4][aarch64] Avoid tag collisions for loads falkor

On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote: Sorry that this took me so long to get to. > > The code is outstanding quality, a textbook example of writing an > analysis/optimization pass using modern GCC frameworks and data > structures! If you ever find the opportunity, I bet

[PATCH] [v2][aarch64] Avoid tag collisions for loads falkor

- Avoid renaming R0/V0 since they could be return values - Fixed minor formatting issues. 2018-07-02 Siddhesh Poyarekar Kugan Vivekanandarajah * config/aarch64/falkor-tag-collision-avoidance.c: New file. * config.gcc (extra_objs): Build it. * config/aarch64

[PING][PATCH, AArch64] Disable reg offset in quad-word store for Falkor

From: Siddhesh Poyarekar <siddh...@sourceware.org> Hi, Jim Wilson posted a patch for this in September[1] and it appears following discussions that the patch was an acceptable fix for falkor. Kugan followed up[2] with a test case since that was requested during initial review. Jim has

[aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

% in CPU2017, with omnetpp_s (4.3%) and pop2_s (2.6%) being the biggest winners. 2018-xx-xx Jim Wilson <jim.wil...@linaro.org> Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org> Siddhesh Poyarekar <siddh...@sourceware.org> gcc/ * gcc/conf

Re: [aarch64][PATCH v2] Disable reg offset in quad-word store for Falkor

On Wednesday 24 January 2018 05:50 PM, Kyrill Tkachov wrote: > I would tend towards making the costs usage more intelligent and > differentiating > between loads and stores but I agree that is definitely GCC 9 material. > Whether this approach is an acceptable stopgap for GCC 8 is up to the >

[PATCH] Fix bogus strncpy source length warning on source bound by constant

Avoid issuing a bogus warning when the source of strncpy is bound by a constant and is known to be less than the size of the destination. Testsuite run is underway (not complete yet, but no new errors so far) and a bootstrap is also underway, I'll report status once they're both done. gcc/

[PATCH v2] Fix bogus strncpy source length warning on source bound by constant

Avoid issuing a bogus warning when the source of strncpy is bound by a constant known to be less than the minimum size of the destination. Changes from v1: - Use range-info instead of the MIN_EXPR hack - Get the minimum size of dst and check for NULL_TREE return The patch bootstraps

Re: [PATCH] Fix bogus strncpy source length warning on source bound by constant

On Monday 12 March 2018 03:26 PM, Richard Biener wrote: > Please use tree_int_cst_lt (rhs1, dstsize) instead. > >> + { >> + gimple_set_no_warning (stmt, true); > > Why this? There's only a single bit -- where do we warn from if you > don't do this here? I incorrectly

Re: [PATCH v2] Fix bogus strncpy source length warning on source bound by constant

On Wednesday 14 March 2018 08:40 PM, Richard Biener wrote: > Instead of building a tree from max you should use > > if (wi::to_widest (max) < wi::to_widest (wi::to_wide (dstsize))) > return; > > given compute_objsize is somewhat confused about the type it returns > a widest_int compare

Re: [PATCH] analyzer: Recognize __builtin_free as a matching deallocator

On 8/25/21 5:44 PM, Matthias Klose wrote: On 7/28/21 1:44 PM, David Malcolm via Gcc-patches wrote: On Wed, 2021-07-28 at 10:34 +0530, Siddhesh Poyarekar wrote: Recognize __builtin_free as being equivalent to free when passed into __attribute__((malloc ())), similar to how it is treated when

Re: [PATCH] Warray-bounds: Warn only for generic address spaces

On 10/13/21 00:36, Martin Sebor wrote: On 10/12/21 12:33 PM, Siddhesh Poyarekar wrote: The warning is falsely triggered for THREAD_SELF in glibc when accessing TCB through the segment register. Thanks for looking into it!  The Glibc warning is being tracked in PR 102630.  The root cause

[PATCH 1/8] __builtin_dynamic_object_size: Recognize builtin name

Recognize the __builtin_dynamic_object_size builtin, but simply replace it with -1 or 0 for now. gcc/ChangeLog: * builtins.c (expand_builtin, fold_builtin_2): Add BUILT_IN_DYN_OBJECT_SIZE. (fold_builtin_dyn_object_size): New function. (valid_object_size_args): New

[PATCH 0/8] __builtin_dynamic_object_size and more

crosses a threshold. I'll take this up once we have more data on the nature of the bottlenecks. Siddhesh Poyarekar (8): __builtin_dynamic_object_size: Recognize builtin name tree-dynamic-object-size: New pass tree-dynamic-object-size: Handle GIMPLE_PHI tree-dynamic-object-size: Support

[PATCH 8/8] tree-dynamic-object-size: Add test wrappers to extend testing

. * gcc.dg/builtin-object-size-16.c: Likewise. * gcc.dg/builtin-object-size-17.c: Likewise. * gcc.dg/builtin-object-size-2.c: Likewise. * gcc.dg/builtin-object-size-3.c: Likewise. * gcc.dg/builtin-object-size-4.c: Likewise. Signed-off-by: Siddhesh Poyarekar --- .../g

[PATCH 6/8] tree-dynamic-object-size: Handle function parameters

, gimplify_size_exprs): Adjust. (parm_object_size): New function. (collect_object_sizes_for): Handle GIMPLE_NOP. gcc/testsuite/ChangeLog: * gcc.dg/builtin-dynamic-object-size-0.c (test_parmsz): New test. (main): Call it. Signed-off-by: Siddhesh Poyarekar

[PATCH 7/8] tree-dynamic-object-size: Get subobject sizes

. (addr_dyn_object_size): Call it. Support subobject size computation. gcc/testsuite/ChangeLog: * gcc.dg/builtin-dynamic-object-size-0.c (test_dynarray_struct_subobj): New test. (main): Call it. Signed-off-by: Siddhesh Poyarekar --- .../gcc.dg/builtin-dynamic-object-size-0.c| 34

[PATCH 2/8] tree-dynamic-object-size: New pass

-off-by: Siddhesh Poyarekar --- gcc/Makefile.in | 19 +- gcc/builtins.c| 8 + gcc/doc/extend.texi | 11 + gcc/passes.def| 3 + .../gcc.dg/builtin-dynamic-object-size-0.c

[PATCH 5/8] tree-dynamic-object-size: Handle GIMPLE_ASSIGN

ct_wholesizes and object_wholesize_exprs. gcc/testsuite/ChangeLog * gcc.dg/builtin-dynamic-object-size-0.c (dynarray_struct): New struct. (test_dynarray_struct, test_substring, test_substring_ptrplus): New tests. (main): Call them. Signed-off-by: Siddh

[PATCH 3/8] tree-dynamic-object-size: Handle GIMPLE_PHI

, test_builtin_malloc_condphi2, test_builtin_malloc_condphi3, test_builtin_calloc_condphi, test_deploop): New tests. (main): Call them. Signed-off-by: Siddhesh Poyarekar --- .../gcc.dg/builtin-dynamic-object-size-0.c| 92 +++ gcc/tree-dynamic-object-size.c| 258

[PATCH 4/8] tree-dynamic-object-size: Support ADDR_EXPR

, test_passthrough_nonssa): New tests. (main): Call them. Signed-off-by: Siddhesh Poyarekar --- gcc/builtins.c| 2 +- .../gcc.dg/builtin-dynamic-object-size-0.c| 37 +++ gcc/tree-dynamic-object-size.c| 255 +- 3

Re: [PATCH] Warray-bounds: Warn only for generic address spaces

On 10/13/21 13:50, Richard Biener wrote: On Tue, Oct 12, 2021 at 8:34 PM Siddhesh Poyarekar wrote: The warning is falsely triggered for THREAD_SELF in glibc when accessing TCB through the segment register. I think this is a more generic bug - the warning is also bogus if the general address

Re: [PATCH 2/8] tree-dynamic-object-size: New pass

On 10/8/21 03:44, Siddhesh Poyarekar wrote: diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 133b82eef38..082d167cd65 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -12777,6 +12777,17 @@ assert (__builtin_object_size (q, 1) == sizeof (var.b)); @end smallexample

Re: [PATCH 0/8] __builtin_dynamic_object_size and more

On 10/8/21 03:44, Siddhesh Poyarekar wrote: (from about 4% to 70% in bash), but that could well be due to the _chk I should also clarify that this is for memcpy. For all fortifiable functions, the coverage percentage went from 30.81% to 84.5% for bash. Below is the full table. Please note

  1   2   3   4   >