Re: divmod pattern question
On Jun 19 2018, Paul Koning wrote: > I have a two-operand divide instruction that takes a double length dividend > in a register pair, and produces the quotient in the first register and > remainder in the second. That's looks like the m68k div insn. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Understanding tree_swap_operands_p wrt SSA name versions
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 trying to get a better understanding of the following part in
> > tree_swap_operands_p():
> >
> > /* It is preferable to swap two SSA_NAME to ensure a canonical form
> > for commutative and comparison operators. Ensuring a canonical
> > form allows the optimizers to find additional redundancies without
> > having to explicitly check for both orderings. */
> > if (TREE_CODE (arg0) == SSA_NAME
> > && TREE_CODE (arg1) == SSA_NAME
> > && SSA_NAME_VERSION (arg0) > SSA_NAME_VERSION (arg1))
> > return 1;
> >
> > My questions in no particular order: It looks like this was added in
> > 2004. I couldn't find any info other than what's in the corresponding
> > commit (cc0bdf913) so I'm wondering if the canonical form/order still
> > relevant/needed today? Does the ordering have to be done based on the
> > name versions specifically? Or can it be based on something more
> > intrinsic to the input source code rather than a GCC internal value, eg:
> > would alphabetic sort order of the variable names be a reasonable
> > replacement?
> Canonicalization is still important and useful.
Indeed.
> However, canonicalizing on SSA_NAMEs is problematical due to the way we
> recycle nodes and re-pack them.
In the past we made sure to not disrupt order - hopefully that didn't change
so the re-packing shoudln't invaidate previous canonicalization:
static void
release_free_names_and_compact_live_names (function *fun)
{
...
/* And compact the SSA number space. We make sure to not change the
relative order of SSA versions. */
for (i = 1, j = 1; i < fun->gimple_df->ssa_names->length (); ++i)
{
> I think defining additional rules for canonicalization prior to using
> SSA_NAME_VERSION as the fallback would be looked upon favorably.
I don't see a good reason to do that, it will be harder to spot canonicalization
issues and it will take extra compile-time.
> Note however, that many of the _DECL nodes referenced by SSA_NAMEs are
> temporaries generated by the compiler and do not correspond to any
> declared/defined object in the original source. So you'll still need
> the SSA_NAME_VERSION (or something as stable or better) canonicalization
> to handle those cases.
And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE names).
Richard.
> Jeff
GCC gfortran doc : correction to documentation
Hello, I have been consulting the documentation for MINLOC: https://gcc.gnu.org/onlinedocs/gfortran/MINLOC.html Thank you for the work you do. I think that when the documentation reads " If more than one element in the array has the minimum value, the location returned is that of the first such element in array element order if the BACK is not present, or if it false; otherwise, the location returned is that of the first such element. " It should read " If more than one element in the array has the minimum value, the location returned is that of the first such element in array element order if the BACK is not present, or if it false; otherwise, the location returned is that of the "LAST" such element. " i.e., replace "first" with "last". Sincerely, Fernando
Re: divmod pattern question
> On Jun 20, 2018, at 1:16 AM, Jeff Law wrote:
>
> On 06/19/2018 12:55 PM, Paul Koning wrote:
>> Gentlepeople,
>>
>> I have a two-operand divide instruction that takes a double length dividend
>> in a register pair, and produces the quotient in the first register and
>> remainder in the second.
>>
>> How do I write a divmod pattern for that? The quotient is easy enough, I
>> write a match_operand for that register and a matching constraint ("0") for
>> the input dividend. But what about the remainder? The remainder appears in
>> a register that isn't explicitly mentioned in the RTL (it's the regnum one
>> higher than the quotient, or if you like, the second subreg of the input
>> (dividend) register.
> You can generally allocate double-sized registers with appropriate
> constraints and the like. And you could use matching constraints,
> perhaps with subregs, but in the end, ew.
>
>>
>> I can make it a define_expand that adds a move from the remainder register
>> into a new register which is the output operand, and count on the optimizer
>> to optimize away that move. Is that the best answer? The current "mod"
>> pattern does that, and I could keep that approach.
> But this would generally be better I think. I'd expect the move to be
> optimized away the vast majority of the time.
Thanks. I looked at some others, like M68k, the difference there is that the
mod result goes to an explicitly named register in the machine instruction.
Here's what I ended up with; it seems to work even though it doesn't match
precisely what the documentation seems to call for.
(define_expand "divmodhi4"
[(parallel
[(set (subreg:HI (match_dup 1) 0)
(div:HI (match_operand:SI 1 "register_operand" "0")
(match_operand:HI 2 "general_operand" "g")))
(set (subreg:HI (match_dup 1) 2)
(mod:HI (match_dup 1) (match_dup 2)))])
(set (match_operand:HI 0 "register_operand" "=r")
(subreg:HI (match_dup 1) 0))
(set (match_operand:HI 3 "register_operand" "=r")
(subreg:HI (match_dup 1) 2))]
"TARGET_40_PLUS"
"")
; and then the actual final instruction:
(define_insn "divmodhi4_nocc"
[(set (subreg:HI (match_operand:SI 0 "register_operand" "=r,r") 0)
(div:HI (match_operand:SI 1 "register_operand" "0,0")
(match_operand:HI 2 "general_operand" "rR,Qi")))
(set (subreg:HI (match_dup 1) 2)
(mod:HI (match_dup 1) (match_dup 2)))
(clobber (reg:CC CC_REGNUM))]
"TARGET_40_PLUS"
"div %2,%0"
[(set_attr "length" "2,4")])
paul
Re: GCC gfortran doc : correction to documentation
CCing the gfortran list. On Wed, 20 Jun 2018 at 12:35, Fernando wrote: > > Hello, > > I have been consulting the documentation for MINLOC: > > https://gcc.gnu.org/onlinedocs/gfortran/MINLOC.html > > Thank you for the work you do. > > I think that when the documentation reads > > " > If more than one element in the array has the minimum value, the location > returned is that of the first such element in array element order if > the BACK is not present, or if it false; otherwise, the location returned is > that of the first such element. > " > > It should read > > " > If more than one element in the array has the minimum value, the location > returned is that of the first such element in array element order if > the BACK is not present, or if it false; otherwise, the location returned is > that of the "LAST" such element. > " > > i.e., replace "first" with "last". > > Sincerely, > Fernando
Re: [GSOC] LTO dump tool project
Hi,
Please find the diff file for dumping tree type stats attached here with.
example:
$ ../stage1-build/gcc/lto1 test_hello.o -fdump-lto-tree-type-stats
Reading object files: test_hello.o
integer_type3
pointer_type3
array_type1
function_type4
I have pushed the changes on Github repo.
Regards,
Hrishikesh
On Mon, Jun 18, 2018 at 2:15 PM, Martin Jambor wrote:
> Hi,
>
> On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am trying to isolate the dump tool into real lto-dump tool. I have
>> started with the copy&paste of lto.c into lto-dump.c and done the
>> changes to Make-lang.in and config-lang.in suggested by Martin (patch
>> attached). However when I try to build, I get the following error:
>>
>> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>>
>> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>>
>> file or directory
>>
>> compilation terminated.
>>
>>
>> I am unable to find the missing dependencies and would be grateful for
>> suggestions on how to resolve the issue.
>
> insn-modes.h is one of header files which are generated at build time,
> you will find it in the gcc subdirectory of your build directory (as
> opposed to the source directory).
>
> Martin
diff --git a/gcc/lto/lang.opt b/gcc/lto/lang.opt
index c10c662..dd506c0 100644
--- a/gcc/lto/lang.opt
+++ b/gcc/lto/lang.opt
@@ -77,6 +77,9 @@ LTO Driver RejectNegative Joined Var(flag_lto_dump_symbol)
demangle
LTO Var(flag_lto_dump_demangle)
+fdump-lto-tree-type-stats
+LTO Var(flag_lto_dump_tree_type_stats)
+
fdump-lto-body=
LTO Driver RejectNegative Joined Var(flag_lto_dump_body)
diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
index afdb76a..760a796 100644
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1799,9 +1799,6 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
data_in->location_cache.accept_location_cache ();
bool seen_type = false;
-
-
-
for (unsigned i = 0; i < len; ++i)
{
tree t = streamer_tree_cache_get_tree (data_in->reader_cache,
@@ -1810,14 +1807,14 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
chains. */
if (TYPE_P (t))
{
- itr = stats.find(TREE_CODE(t));
- if (itr == stats.end())
+ if (flag_lto_dump_tree_type_stats)
{
-stats.insert(std :: pair (TREE_CODE(t), 1));
- }
- else
-itr->second++;
-
+itr = stats.find(TREE_CODE(t));
+if (itr == stats.end())
+ stats.insert(std :: pair (TREE_CODE(t), 1));
+else
+ itr->second++;
+ }
seen_type = true;
num_prevailing_types++;
lto_fixup_prevailing_type (t);
@@ -1865,10 +1862,9 @@ lto_read_decls (struct lto_file_decl_data *decl_data, const void *data,
}
}
fprintf(stderr, "\n");
-for (itr = stats.begin(); itr != stats.end(); ++itr)
-{
- fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
-}
+if (flag_lto_dump_tree_type_stats)
+ for (itr = stats.begin(); itr != stats.end(); ++itr)
+fprintf(stderr, "\t%s\t%d\n", get_tree_code_name(itr->first), itr->second );
data_in->location_cache.apply_location_cache ();
-Wno-format-contains-nul
Years and years ago, I went to a mess of trouble to implement this specialized warning so I would not have to see it anymore. I use a code generator that puts constant strings into one huge buffer with all the contained strings NUL separated. Today, I was trying to build on OS/X: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2 -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD -MP -MF .deps/libopts_la-libopts.Tpo -c libopts.c -fno-common -DPIC -o .libs/libopts_la-libopts.o warning: unknown warning option '-Wno-format-contains-nul' [-Wunknown-warning-option] In file included from libopts.c:26: ./enum.c:112:38: warning: format string contains '\0' within the string body [-Wformat] fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++)); ^ ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE' #define ENUM_ERR_LINE (ao_strs_strtable+304) ^~ ./ao-strs.c:90:20: note: format string is defined here /* 304 */ " %s\n\0" ~~~^~~ Did somebody go to a bunch of trouble to undo my work for the OS/X platform? :( -- - Bruce
ICE in a testcase, not sure about solution
I'm running into an ICE in the GIMPLE phase, for gcc.c-torture/compile/386.c,
on pdp11 -mint32. That's an oddball where int is 32 bits (due to the flag) but
Pmode is 16 bits (HImode).
The ICE message is:
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c: In function ‘main’:
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c:24:1: error: invalid types
in nop conversion
}
^
int
int *
b_3 = (int) &i;
during GIMPLE pass: einline
../../gcc/gcc/testsuite/gcc.c-torture/compile/386.c:24:1: internal compiler
error: verify_gimple failed
The offending code snippet is (I think):
main ()
{
int i;
foobar (i, &i);
}
foobar (a, b)
{
int c;
c = a % b;
a = a / b;
return a + b;
}
where the foobar(i, &i) call passes an int* to a (defaulted) int function
parameter. Is there an assumption that sizeof (int*) >= sizeof(int)?
Any idea where to look? It only shows up with -mint32; if int is 16 bits all
is well. I'm not used to my target breaking things before I even get to RTL...
paul
Re: -Wno-format-contains-nul
On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote: > Years and years ago, I went to a mess of trouble to implement this > specialized warning so I would not have to see it anymore. I use a code > generator that puts constant strings into one huge buffer with all the > contained strings NUL separated. Today, I was trying to build on OS/X: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2 > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul > -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD -MP > -MF .deps/libopts_la-libopts.Tpo -c libopts.c -fno-common -DPIC -o > .libs/libopts_la-libopts.o > > warning: unknown warning option '-Wno-format-contains-nul' > [-Wunknown-warning-option] > In file included from libopts.c:26: > ./enum.c:112:38: warning: format string contains '\0' within the string > body [-Wformat] > fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++)); > ^ > ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE' > #define ENUM_ERR_LINE (ao_strs_strtable+304) > ^~ > ./ao-strs.c:90:20: note: format string is defined here > /* 304 */ " %s\n\0" > ~~~^~~ > > > Did somebody go to a bunch of trouble to undo my work for the OS/X > platform? :( No, you are probably just using clang rather than gcc. gcc has no -Wunknown-warning-option warning, -Wformat-contains-nul is a known option and if you used some unknown -Wno-... warning option and any diagnostics was emitted, the message would be just: warning: unrecognized command line option ‘-Wno-whatever’ Jakub
Re: -Wno-format-contains-nul
Thanks. I guess clang forked after the clever NUL-in-format-string was added, but before my fix. :( I'll add -Wno-format if I can identify clang over GCC. On Wed, Jun 20, 2018 at 11:32 AM Jakub Jelinek wrote: > On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote: > > Years and years ago, I went to a mess of trouble to implement this > > specialized warning so I would not have to see it anymore. I use a code > > generator that puts constant strings into one huge buffer with all the > > contained strings NUL separated. Today, I was trying to build on OS/X: > > > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2 > > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > > -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul > > -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD > -MP > > -MF .deps/libopts_la-libopts.Tpo -c libopts.c -fno-common -DPIC -o > > .libs/libopts_la-libopts.o > > > > warning: unknown warning option '-Wno-format-contains-nul' > > [-Wunknown-warning-option] > > In file included from libopts.c:26: > > ./enum.c:112:38: warning: format string contains '\0' within the string > > body [-Wformat] > > fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++)); > > ^ > > ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE' > > #define ENUM_ERR_LINE (ao_strs_strtable+304) > > ^~ > > ./ao-strs.c:90:20: note: format string is defined here > > /* 304 */ " %s\n\0" > > ~~~^~~ > > > > > > Did somebody go to a bunch of trouble to undo my work for the OS/X > > platform? :( > > No, you are probably just using clang rather than gcc. > gcc has no -Wunknown-warning-option warning, -Wformat-contains-nul > is a known option and if you used some unknown -Wno-... warning option > and any diagnostics was emitted, the message would be just: > warning: unrecognized command line option ‘-Wno-whatever’ > > Jakub > -- - Bruce
Next question: sizeof(char buf[2042])
Yeah, I guess this is Clang, but is it a legal interpretation for Clang? In file included from gnu-pw-mgr.c:24: In file included from ./fwd.h:288: *./seed.c:178:43: **warning: **sizeof on pointer operation will return size of 'const char *' instead of 'const char [2042]'* * [-Wsizeof-array-decay]* char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG))); * ^~~* *It seems like a pretty brain damaged interpretation.* -- - Bruce
Re: Next question: sizeof(char buf[2042])
OK. My mistake. "Nevermind" -- side effect of another change. On Wed, Jun 20, 2018 at 11:47 AM Bruce Korb wrote: > Yeah, I guess this is Clang, but is it a legal interpretation for Clang? > > In file included from gnu-pw-mgr.c:24: > > In file included from ./fwd.h:288: > > *./seed.c:178:43: **warning: **sizeof on pointer operation will return > size of 'const char *' instead of 'const char [2042]'* > > * [-Wsizeof-array-decay]* > > char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG))); > > * ^~~* > > > *It seems like a pretty brain damaged interpretation.* > > -- > - Bruce > -- - Bruce
Re: Next question: sizeof(char buf[2042])
On Wed, Jun 20, 2018 at 11:47:45AM -0700, Bruce Korb wrote: > Yeah, I guess this is Clang, but is it a legal interpretation for Clang? > > In file included from gnu-pw-mgr.c:24: > > In file included from ./fwd.h:288: > > *./seed.c:178:43: **warning: **sizeof on pointer operation will return size > of 'const char *' instead of 'const char [2042]'* > > * [-Wsizeof-array-decay]* > > char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG))); > > * ^~~* > > > *It seems like a pretty brain damaged interpretation.* We'd need to see the code but the warning seems legit. What's the problem? Marek
2019 MIPIM Yacht Charters
Experience Cannes in style on a Corporate Yacht Charter (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YOr52YVi7UwEsDGMNmBD9Mw-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2Brt7-2BnLgLPfxz3M0o1is-2FfpV3R010QzOFYFyYXlW4NARfDXAKbeBcnHrGh-2BTUbykLd8c4bJoZljFTVPc6mWrpTjvQLtx-2Bnq-2BstF4359crVLZHrlWo5Nt9WQ38terqhSmITkwM6UuDjIrvdKLKKZKtsw-3D-3D CANNES, FRANCE (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2B7rwZ-2FckH2bE1lOGTjORQgog-2FXcStwZNQjp3jXgjgWu5-2Bb0YkEa4jryfQ1fgBw-2BwkXGrBsCzG0WG-2BRX-2FQWJ1XvIahZhluqBVTxAOjMbjFYNZiJa8WtsG7TtPkVdmr3sJ92Tfj1N1DcuLlOQuPjixO0Q-3D-3D 12 to 15 March 2019 (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BL4I-2B5gEtY4BUGIfClqeBXF6UpwFSc9EATfF208QT4f8RHKoeU3cusLXJzxo40Lwz7k6w-2BXUsgwhTHmRDMrTqWSyi0GJ2VhWfY6SeIk25XEcl6CnaRcDmJT9lA9xW-2FQzcX-2FKkYoqqn-2FyGkW-2Bc-2BWroJQ-3D-3D MIPIM 2019 (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BJilYz1iBlGxtKiJSzxThw0OjHqXLa7ySNAYrLsxt5RNHAx3il4CCA2-2BNtRTcFrhqxiI6S6G-2Flf4-2BMHZz-2BMOf-2Fon057qONNiESE8EgEIG-2Fk8kVpC8-2BlzdOMDS20AIZHelwG2ylHZI1mQNnqgqO-2Bxvog-3D-3D The World’s Leading Commercial Property Market (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BMFjaA7L8SBNJf0Yh5jyOoHFJdoTGoWJ53jidFuWoGTvv6-2BtZiJ-2BgPyoViW7A8989lp1jjyoZ-2F4F4-2B0c-2BQKFqN1Esv6YpqlRqCb6-2BUILz6EK1Zu2CLYMjHMzd8tsd5LtO-2FsEkiD10bKvgc0IYkx1fRQ-3D-3D CANNES YACHT CHARTERS (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BJz1qNlnBKtjuv-2Bl7ufMX-2Fqu6-2F3QgkYbPGvxqcJwXjDP5-2FCBkbacjvJQL3GxM3P-2B-2FZ-2BdaW0KH-2BQN9Zbt8xH3e5wDRsaXQdX5qL2LMq6lIoLu8DiNsYlxrOFTHakvQ425XeDoOJILVny8Csk3se-2BAuuA-3D-3D Since 1998, we have offering the finest luxury yacht charters (mailto:j...@ultimate-charters.com?subject=Yacht%20Charters) on the French Riviera, from Cannes to Monaco & St. Tropez. We specialize in corporate yacht charters (mailto:j...@ultimate-charters.com?subject=Yacht%20Charters) for events like MIPIM, MAPIC, Cannes Lions, MIDEM, MIPTV, the Cannes Film Festival & the Monaco Grand Prix. Contact us (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BBnFv-2BmhGjCObgH1M3dHlu6grt4VWzaYrYZMf2nBWPwHOnOMQSiF3mPSH9SeOU4s4hq4g8whgA-2Fns968oVLQJHN2eICnY5VFnmwXvFgXme4DRpAY9mcPGsL1i1XU86dq7odP8Y5WVb0f2f3rxpVOLuQ-3D-3D to explore the endless possibilities. AVAILABLE YACHTS IN CANNES (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBXaB-2FYYKlCKtMMYe-2FhaMSU8PMGERa5ZhfyZIoSX27ltFvD4ezOCjTbU-2BOxC0aACuna7FfQ0zO02y9rB8oliiHYAQjCfwLCrnyh21d5a32xKeg-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BSJXu0YOwQkspLvAc-2B2fobmpbY3Bql8jO0FmeU-2F0FoFAB-2FkHz9k2fzSoBvq-2BLYZFWedfT7r91KSYuLeHbY9c5usb-2B8KnhHXkj-2FCIGbNYNGuN4bpLNA6cO09EaB5FT2gz-2Fy4-2Bu8gydRibM1cqJI-2BuW4A-3D-3D M/Y Princess, 75ft/23m (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBXaB-2FYYKlCKtMMYe-2FhaMSU8PMGERa5ZhfyZIoSX27ltFvD4ezOCjTbU-2BOxC0aACuna7FfQ0zO02y9rB8oliiHYABhDCGXr-2B6cMBO3yfL5REXQ-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BR7SW-2BCVWb6eFho-2FnWXMsh6veg2Bfr0TzklV3oKW0SCWzOfl3FR6p2LopvpRPFHMiWjla30NlK1fWm0jixrWPB5IR95vlIS0FWNokFRYI65SnIsJ2Gpm3LAI8hj7O1cMJo0Uo8H01WshKjLw4BWZQqQ-3D-3D Beautiful flybridge motor yacht with 4 Cabins, 3 Meeting Areas, Entertains up to 12. Daily Rate: 8,335€ (+ charges). More Details (mailto:j...@ultimate-charters.com?subject=Yacht%20Charters) (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR3d-2FR9fRvTiX3jMD42Aa63RX3G1cmVpk5p2CXwpUNZbHyoN4Gmkj0CQsf-2BU2djVFjykkn-2FgvjutfuXviRc9X-2FC2wZpAHdLtk3XJIibLQo0RSOocxZ1aK6ZjZXdpEALVei6cTIIAP6hSWstvsTdWtgE1mCSeeHNTyyPa8fdtKtknLEA7zmswO-2B-2B5G2xvUl6mNc4EZcv37Ngedb6lw-3D-3D (https://u7419970.ct.sendgrid.net/wf/click?upn=FBDq8VEpDC2W9whzzZ5c9UJyWBG4s3G5UcA5SNxaxBVGA9wckcjt9k-2FbhUn2dI9YwsrvwhSJMuMi6qd4z8Hr2Q-3D-3D_iaYFtpR
Re: How to get GCC on par with ICC?
On Wed, Jun 6, 2018 at 11:57 AM, Joel Sherrill wrote:
>
> On Wed, Jun 6, 2018 at 10:51 AM, Paul Menzel <
> pmenzel+gcc.gnu@molgen.mpg.de> wrote:
>
> > Dear GCC folks,
> >
> >
> > Some scientists in our organization still want to use the Intel compiler,
> > as they say, it produces faster code, which is then executed on clusters.
> > Some resources on the Web [1][2] confirm this. (I am aware, that it’s
> > heavily dependent on the actual program.)
> >
>
> Do they have specific examples where icc is better for them? Or can point
> to specific GCC PRs which impact them?
>
>
> GCC versions?
>
> Are there specific CPU model variants of concern?
>
> What flags are used to compile? Some times a bit of advice can produce
> improvements.
>
> Without specific examples, it is hard to set goals.
If I could perhaps jump in here for a moment... Just today I hit upon
a series of small (in lines of code) loops that gcc can't vectorize,
and intel vectorizes like a madman. They all involve a lot of heavy
use of std::vector>. Comparisons were with gcc
8.1, intel 2018.u1, an AMD Opteron 6386 SE, with the program running
as sched_FIFO, mlockall, affinity set to its own core, and all
interrupts vectored off that core. So, as close to not-noisy as
possible.
I was surprised at the results results, but using each compiler's methods of
dumping vectorization info, intel wins on two points:
1) It actually vectorizes
2) It's vectorizing output is much more easily readable
Options were:
gcc -Wall -ggdb3 -std=gnu++17 -flto -Ofast -march=native
vs:
icc -Ofast -std=gnu++14
So, not exactly exact, but pretty close.
So here's an example of a chunk of code (not very readable, sorry
about that) that intel can vectorize, and subsequently make about 50%
faster:
std::size_t nLayers { input.nn.size() };
//std::size_t ySize = std::max_element(input.nn.cbegin(),
input.nn.cend(), [](auto a, auto b){ return a.size() < b.size();
})->size();
std::size_t ySize = 0;
for (auto const & nn: input.nn)
ySize = std::max(ySize, nn.size());
float yNorm[ySize];
for (auto & y: yNorm)
y = 0.0f;
for (std::size_t i = 0; i < xSize; ++i)
yNorm[i] = xNorm[i];
for (std::size_t layer = 0; layer < nLayers; ++layer) {
auto & nn = input.nn[layer];
auto & b = nn.back();
float y[ySize];
for (std::size_t i = 0; i < nn[0].size(); ++i) {
y[i] = b[i];
for (std::size_t j = 0; j < nn.size() - 1; ++j)
y[i] += nn.at(j).at(i) * yNorm[j];
}
for (std::size_t i = 0; i < ySize; ++i) {
if (layer < nLayers - 1)
y[i] = std::max(y[i], 0.0f);
yNorm[i] = y[i];
}
}
If I was better at godbolt, I could show the asm, but I'm not. I'm
willing to learn, though.
gcc-6-20180620 is now available
Snapshot gcc-6-20180620 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180620/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 261826 You'll find: gcc-6-20180620.tar.xzComplete GCC SHA256=1fb3964f685326c13e8a10c3b98c679f3b1e33b1d9f18773525664f8ee926eb5 SHA1=57baf7bd49cc9f73edc00584adf9c134f0693b63 Diffs from 6-20180613 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: LTO and other test failures on trunk
On Mon, 2018-06-18 at 10:22 -0600, Martin Sebor wrote: > David, > > Have you been able to reproduce the jit test failures below on > tor? Is there some information I can get you from my builds to > help you debug it? Thanks for pointing it out. I've started seeing it on my machine. They appear to have been due to recent(?) changes to IPA; I've posted a patch for the issue here: "[PATCH] Fix IPA crash in libgccjit" https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01282.html Dave
