Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'

> It seems the a-except.adb was replaced by a-except-2005.adb in this commit: Right, it's by design, the old support for SJLJ exceptions has been ditched for full runtimes. You probably just need to swap the values of Frontend_Exceptions : constant Boolean := True; ZCX_By_Default

For help:Unexpected fail about testsuite of GCC

Hi, I have run the testsuite of GCC and compared with results from a similar configuration in the gcc-testresults mailing list, the results just have a little difference. Both of the results have many unexpected fails, I want to know why they failed but the log couldn’t affort enough info

Re: For help:Unexpected fail about testsuite of GCC

On Tue, 3 Jul 2018 at 08:11, 陈龙 wrote: > > Hi, > > > > I have run the testsuite of GCC and compared with results from a similar > configuration in the gcc-testresults mailing list, the results just have a > little difference. Both of the results have many unexpected fails, I want to > know wh

DSE and maskstore trouble

Hi All, I'm trying to implement maskload/maskstore for AMD GCN, which has up-to 64-lane, 512-byte fully-masked vectors. All seems fine as far as the vector operations themselves go, but I've found a problem with the RTL Dead Store Elimination pass. Testcase gcc.c-torture/execute/20050826-2.c

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 11:59 AM Andrew Stubbs wrote: > > Hi All, > > I'm trying to implement maskload/maskstore for AMD GCN, which has up-to > 64-lane, 512-byte fully-masked vectors. All seems fine as far as the > vector operations themselves go, but I've found a problem with the RTL > Dead Store

Re: DSE and maskstore trouble

On 03/07/18 11:15, Richard Biener wrote: AVX ones are all UNSPECs I believe - how do your patterns look like? AVX has both unspec and vec_merge variants (at least for define_expand, in GCC8), but in any case, AFAICT dse.c only cares about the destination MEM, and all the AVX and SVE patterns

Re: DSE and maskstore trouble

On 03/07/18 11:33, Andrew Stubbs wrote: On 03/07/18 11:15, Richard Biener wrote: AVX ones are all UNSPECs I believe - how do your patterns look like? AVX has both unspec and vec_merge variants (at least for define_expand, in GCC8), but in any case, AFAICT dse.c only cares about the destinatio

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 12:57 PM Andrew Stubbs wrote: > > On 03/07/18 11:33, Andrew Stubbs wrote: > > On 03/07/18 11:15, Richard Biener wrote: > >> AVX ones are all UNSPECs I believe - how do your patterns look like? > > > > AVX has both unspec and vec_merge variants (at least for define_expand, >

Re: DSE and maskstore trouble

On 03/07/18 12:02, Richard Biener wrote: I believe that the AVX variants like (define_expand "maskstore" [(set (match_operand:V48_AVX512VL 0 "memory_operand") (vec_merge:V48_AVX512VL (match_operand:V48_AVX512VL 1 "register_operand") (match_dup 0) (mat

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 1:06 PM Andrew Stubbs wrote: > > On 03/07/18 12:02, Richard Biener wrote: > > I believe that the AVX variants like > > > > (define_expand "maskstore" > >[(set (match_operand:V48_AVX512VL 0 "memory_operand") > > (vec_merge:V48_AVX512VL > >(match_opera

Re: DSE and maskstore trouble

On 03/07/18 12:30, Richard Biener wrote: Hmm, so they're safe, but may prevent the optimization of nearby variables? Yes, they prevent earlier stores into lanes that are "really" written to to be DSEd. Right, but I have unrelated variables allocated to the stack within the "shadow" of the ma

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs wrote: > > On 03/07/18 12:30, Richard Biener wrote: > >> Hmm, so they're safe, but may prevent the optimization of nearby variables? > > > > Yes, they prevent earlier stores into lanes that are "really" written > > to to be DSEd. > > Right, but I have u

Re: DSE and maskstore trouble

On 03/07/18 12:45, Richard Biener wrote: On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs wrote: On 03/07/18 12:30, Richard Biener wrote: Hmm, so they're safe, but may prevent the optimization of nearby variables? Yes, they prevent earlier stores into lanes that are "really" written to to be DS

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 1:57 PM Andrew Stubbs wrote: > > On 03/07/18 12:45, Richard Biener wrote: > > On Tue, Jul 3, 2018 at 1:38 PM Andrew Stubbs > > wrote: > >> > >> On 03/07/18 12:30, Richard Biener wrote: > Hmm, so they're safe, but may prevent the optimization of nearby > variable

Re: DSE and maskstore trouble

On 03/07/18 13:21, Richard Biener wrote: Ok, so if we vectorize the above with 64 element masked stores then indeed the RTL representation is _not_ safe. That is because while the uses in the masked stores should prevent things from going bad there is also TBAA to consider which means those uses

Re: [GSOC] LTO dump tool project

Hi, Thanks for suggestions. I have started incorporating them. As a first: I have added command line options: -print-size to print the size of functions and variables size of variables is in bits and size of functions is represented as number of basic blocks. -print-value to print the value of

Re: DSE and maskstore trouble

On Tue, Jul 3, 2018 at 2:46 PM Andrew Stubbs wrote: > > On 03/07/18 13:21, Richard Biener wrote: > > Ok, so if we vectorize the above with 64 element masked stores > > then indeed the RTL representation is _not_ safe. That is because > > while the uses in the masked stores should prevent things f

Re: Understanding tree_swap_operands_p wrt SSA name versions

On 2018-06-20 04:23 AM, Richard Biener wrote: > On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: >> >> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote: >>> Hi everyone, >>> >>> (I hope this is the right place to ask, if not my apologies; please >>> point me in the right direction) >>> >>> I'm tryi

Re: DSE and maskstore trouble

On 03/07/18 14:52, Richard Biener wrote: If you look at RTL dumps (with -fstrict-aliasing, thus -O2+) you should see MEM_ALIAS_SETs differing for the earlier stores and the masked store uses. Now I'm of course assuming DSE is perfect, maybe it isn't ... ;) Ok, I see that the stores have MEMs w

Question on -fopt-info-inline

Hi, In order to collect complete information on all the inlining transformation that GCC applies on a given program, I searched online, and found that the option -fopt-info-inline might be the right option to use: https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html

Re: DSE and maskstore trouble

On July 3, 2018 5:19:24 PM GMT+02:00, Andrew Stubbs wrote: >On 03/07/18 14:52, Richard Biener wrote: >> If you look at RTL dumps (with -fstrict-aliasing, thus -O2+) you >should >> see MEM_ALIAS_SETs differing for the earlier stores and the masked >> store uses. >> >> Now I'm of course assuming D

Re: Understanding tree_swap_operands_p wrt SSA name versions

On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov wrote: >On 2018-06-20 04:23 AM, Richard Biener wrote: >> On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: >>> >>> On 06/19/2018 12:30 PM, Michael Ploujnikov wrote: Hi everyone, (I hope this is the right place to ask, if not m

Re: Question on -fopt-info-inline

On July 3, 2018 6:01:19 PM GMT+02:00, Qing Zhao wrote: >Hi, > >In order to collect complete information on all the inlining >transformation that GCC applies on a given program, >I searched online, and found that the option -fopt-info-inline might be >the right option to use: > >https://gcc.gnu.org

Re: Question on -fopt-info-inline

> On Jul 3, 2018, at 11:48 AM, Richard Biener > wrote: > > On July 3, 2018 6:01:19 PM GMT+02:00, Qing Zhao > wrote: >> Hi, >> >> In order to collect complete information on all the inlining >> transformation that GCC applies on a given program, >> I searched onli

Re: Understanding tree_swap_operands_p wrt SSA name versions

On 2018-07-03 12:46 PM, Richard Biener wrote: > On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov > wrote: >> On 2018-06-20 04:23 AM, Richard Biener wrote: >>> On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: On 06/19/2018 12:30 PM, Michael Ploujnikov wrote: > Hi everyone, >>

Re: Question on -fopt-info-inline

>> >>> >>> In order to collect complete information on all the inlining >>> transformation that GCC applies on a given program, >>> I searched online, and found that the option -fopt-info-inline might be >>> the right option to use: >>> >>> https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.

Re: Understanding tree_swap_operands_p wrt SSA name versions

On 07/03/2018 11:55 AM, Michael Ploujnikov wrote: > On 2018-07-03 12:46 PM, Richard Biener wrote: >> On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov >> wrote: >>> On 2018-06-20 04:23 AM, Richard Biener wrote: On Wed, Jun 20, 2018 at 7:31 AM Jeff Law wrote: > > On 06/19/2018

Re: Question on -fopt-info-inline

On 07/03/2018 12:28 PM, Qing Zhao wrote: > >>> In order to collect complete information on all the inlining transformation that GCC applies on a given program, I searched online, and found that the option -fopt-info-inline might be the right option to use: https:

Re: RISC-V and Ada: undefined references to `__gnat_raise_nodefer_with_msg'

On 03/07/18 09:10, Eric Botcazou wrote: It seems the a-except.adb was replaced by a-except-2005.adb in this commit: Right, it's by design, the old support for SJLJ exceptions has been ditched for full runtimes. You probably just need to swap the values of Frontend_Exceptions : const

Sched1 stability issue

Hi, We noticed a difference in the code generated for aarch64 gcc 7.2 hosted in Linux vs mingw. AFIK, we are supposed to produce the same output. For the testacse we have (quite large and I am trying to reduce), the difference comes from sched1 pass. If I disable sched1 the difference is going aw