RE: loading of zeros into {x,y,z}mm registers
Jan,
In case of AVX512 we need to support higher vector registers. We have to work
with xmm16-xmm31 in this case.
Sergey
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jan
Beulich
Sent: Wednesday, November 29, 2017 5:00 PM
To: Kirill Yukhin
Cc: gcc@gcc.gnu.org
Subject: loading of zeros into {x,y,z}mm registers
Kirill,
in an unrelated context I've stumbled across a change of yours from Aug 2014
(revision 213847) where you "extend" the ways of loading zeros into registers.
I don't understand why this was done, and the patch submission mail also
doesn't give any reason.
My point is that simple VEX-encoded vxorps/vxorpd/vpxor with 128-bit register
operands ought to be sufficient to zero any width registers, due to the zeroing
of the high parts the instructions do.
Hence by using EVEX encoded insns it looks like all you do is grow the
instruction length by one or two bytes (besides making the source somewhat more
complicated to follow). At the very least the shorter variants should be used
for -Os imo.
Thanks for any insight,
Jan
GCC 7.3 timeline?
Hi all; are we on track to have a GCC 7.3 sometime in the next few weeks, as per usual for the last few years? Not looking for a date, just a feeling. I'm not sure why my toolchain rollouts always seem to fall right around the time of a new fix release for GCC... Thanks!
targetm.calls.promote_prototypes parameter
It seems that when DJ converted TARGET_PROMOTE_PROTOTYPES to a hook, he added a parameter type that was never documented; the name and its initial usage indicate that it was intended to get the type of a function. Later Kazu converted remaining uses of the macro to use the hook, but those calls pass the individual parameter type instead. SH seems to be the only target that cares about the parameter; is this inconsistency causing trouble there? Jason
Re: GCC 7.3 timeline?
On December 6, 2017 3:29:28 PM GMT+01:00, Paul Smith wrote: >Hi all; are we on track to have a GCC 7.3 sometime in the next few >weeks, as per usual for the last few years? Not looking for a date, >just a feeling. > >I'm not sure why my toolchain rollouts always seem to fall right around >the time of a new fix release for GCC... I expect an announcement before Christmas but a RC and the release only next year. Richard. >Thanks!
Re: targetm.calls.promote_prototypes parameter
In my original proposal, I said this:
> It includes a bunch of macro->hook conversions, mostly because the
> hooks need an additional parameter (the function) to detect which ones
> are Renesas ABI and which are GCC ABI.
The original documentation at least hinted that the parameter was a
function type:
> @deftypefn {Target Hook} bool TARGET_PROMOTE_PROTOTYPES (tree @var{fntype})
Kazu's calls are in the C++ stuff, I don't know if g++ and Renesas C++
are compatible anyway (I doubt it), but that's what would be affected.
The original work was for C compatibility.
Re: targetm.calls.promote_prototypes parameter
On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
>
> In my original proposal, I said this:
>
> > It includes a bunch of macro->hook conversions, mostly because the
> > hooks need an additional parameter (the function) to detect which ones
> > are Renesas ABI and which are GCC ABI.
>
> The original documentation at least hinted that the parameter was a
> function type:
>
> > @deftypefn {Target Hook} bool TARGET_PROMOTE_PROTOTYPES (tree @var{fntype})
>
> Kazu's calls are in the C++ stuff, I don't know if g++ and Renesas C++
> are compatible anyway (I doubt it), but that's what would be affected.
> The original work was for C compatibility.
The C FE seems to pass the fntype, while C++ FE seems to pass
the type of the param.
Jakub
glue file built with compiler in PATH in out of tree testing
Hi, TL;DR: where to tell dejagnu about the compiler to use for building testglue? == context == I've just found out that testglue.c is built using the compiler in PATH when doing out of tree testing rather than using the one specified by GCC_UNDER_TEST (or other *_UNDER_TEST). This is because testglue is built using build_wrapper in gcc/testsuite/lib/wrapper.exp which ultimately calls default_target_compile most of the time. The compiler is then looked for in the options (something starting with ^compiler), then in CC_FOR_TARGET (or similar *_FOR_TARGET) and then default to use the one in the PATH. == problem == I'm not sure where is the proper place to fix this. Obviously setting CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would work but I wonder if this would not be better fixed somewhere else? The rest of the testsuite seems happy with using GCC_UNDER_TEST, so surely testglue should be using the same thing? Should this be done in wrapper.exp? If yes, should we set *_FOR_TARGET? I don't see a way to pass ^compiler to build_wrapper's $flag variable. Best regards, Thomas
question about inlining
While testing a libstdc++ patch that relies on inlining to
expose a GCC limitation I noticed that the same member function
of a class template is inlined into one function in the test but
not into the other, even though it is inlined into each if each
is compiled separately (i.e., in a file on its own).
I wasn't aware that inlining decisions made in one function could
affect those in another, or in the whole file. Is that expected?
And if yes, what's the rationale?
Here's a simplified test case. When compiled with -O2 or -O3
and either just -DFOO or just -DBAR, the call to vector::resize()
and all the functions called from it, including (crucially)
vector::_M_default_append, are inlined. But when compiled with
-DFOO -DBAR _M_default_append is not inlined. With a somewhat
more involved test case I've also seen the first call inlined
but not the second, which was also surprising to me.
#include
void sink (std::vector&);
#if FOO
void foo (unsigned n)
{
std::vector a;
a.resize (n);
sink (a);
}
#endif
#if BAR
void bar (unsigned long n)
{
std::vector a;
a.resize (n);
sink (a);
}
#endif
Thanks
Martin
Re: glue file built with compiler in PATH in out of tree testing
On Wed, 6 Dec 2017, Thomas Preudhomme wrote: > == problem == > > I'm not sure where is the proper place to fix this. Obviously setting > CC_FOR_TARGET in contrib/test_installed or when calling runtest manually would > work but I wonder if this would not be better fixed somewhere else? The rest > of the testsuite seems happy with using GCC_UNDER_TEST, so surely testglue > should be using the same thing? Should this be done in wrapper.exp? If yes, > should we set *_FOR_TARGET? I don't see a way to pass ^compiler to > build_wrapper's $flag variable. One possibility is something along the lines of set_board_info compiler "[find_gcc]" or set_board_info compiler $CC set_board_info c++compiler $CXX in your board file (and site.exp setting CC, CXX etc.). I believe the thus-specified compiler will also be used for e.g. GDB testing. (I'd also expect the compiler being tested to be in the PATH when doing installed testing.) -- Joseph S. Myers jos...@codesourcery.com
Overdue payment
I have tracked this order and it was delivered on 12/06/2017 @ 01:54. The tracking number is Fedex #48876355336. If you have anymore questions please call me. http://www.americaneskimopups.com/Order-Confirmation/ Best wishes, Xen-devel
Re: question about inlining
On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor wrote:
>While testing a libstdc++ patch that relies on inlining to
>expose a GCC limitation I noticed that the same member function
>of a class template is inlined into one function in the test but
>not into the other, even though it is inlined into each if each
>is compiled separately (i.e., in a file on its own).
>
>I wasn't aware that inlining decisions made in one function could
>affect those in another, or in the whole file. Is that expected?
>And if yes, what's the rationale?
>
>Here's a simplified test case. When compiled with -O2 or -O3
>and either just -DFOO or just -DBAR, the call to vector::resize()
>and all the functions called from it, including (crucially)
>vector::_M_default_append, are inlined. But when compiled with
>-DFOO -DBAR _M_default_append is not inlined. With a somewhat
>more involved test case I've also seen the first call inlined
>but not the second, which was also surprising to me.
There are unit and function growth limits that can be hit.
> #include
>
> void sink (std::vector&);
>
> #if FOO
> void foo (unsigned n)
> {
> std::vector a;
> a.resize (n);
> sink (a);
> }
> #endif
>
> #if BAR
> void bar (unsigned long n)
> {
> std::vector a;
> a.resize (n);
> sink (a);
> }
> #endif
>
>Thanks
>Martin
Re: targetm.calls.promote_prototypes parameter
On Wed, Dec 6, 2017 at 12:14 PM, Jakub Jelinek wrote:
> On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
>>
>> In my original proposal, I said this:
>>
>> > It includes a bunch of macro->hook conversions, mostly because the
>> > hooks need an additional parameter (the function) to detect which ones
>> > are Renesas ABI and which are GCC ABI.
>>
>> The original documentation at least hinted that the parameter was a
>> function type:
>>
>> > @deftypefn {Target Hook} bool TARGET_PROMOTE_PROTOTYPES (tree @var{fntype})
>>
>> Kazu's calls are in the C++ stuff, I don't know if g++ and Renesas C++
>> are compatible anyway (I doubt it), but that's what would be affected.
>> The original work was for C compatibility.
>
> The C FE seems to pass the fntype, while C++ FE seems to pass
> the type of the param.
I'm inclined to change the C++ FE to pass NULL_TREE instead until such
time as someone cares.
Jason
Re: targetm.calls.promote_prototypes parameter
On Wed, Dec 06, 2017 at 02:27:55PM -0500, Jason Merrill wrote:
> On Wed, Dec 6, 2017 at 12:14 PM, Jakub Jelinek wrote:
> > On Wed, Dec 06, 2017 at 11:47:41AM -0500, DJ Delorie wrote:
> >>
> >> In my original proposal, I said this:
> >>
> >> > It includes a bunch of macro->hook conversions, mostly because the
> >> > hooks need an additional parameter (the function) to detect which ones
> >> > are Renesas ABI and which are GCC ABI.
> >>
> >> The original documentation at least hinted that the parameter was a
> >> function type:
> >>
> >> > @deftypefn {Target Hook} bool TARGET_PROMOTE_PROTOTYPES (tree
> >> > @var{fntype})
> >>
> >> Kazu's calls are in the C++ stuff, I don't know if g++ and Renesas C++
> >> are compatible anyway (I doubt it), but that's what would be affected.
> >> The original work was for C compatibility.
> >
> > The C FE seems to pass the fntype, while C++ FE seems to pass
> > the type of the param.
>
> I'm inclined to change the C++ FE to pass NULL_TREE instead until such
> time as someone cares.
Well, in PR82897 I had a potential use for it, but one of the obstackles was
that when the C++ FE calls these the function type isn't around.
Jakub
Re: targetm.calls.promote_prototypes parameter
Jason Merrill writes: > I'm inclined to change the C++ FE to pass NULL_TREE instead until such > time as someone cares. The sh backend will at least not choke on that ;-)
Re: targetm.calls.promote_prototypes parameter
On Wed, Dec 6, 2017 at 2:31 PM, DJ Delorie wrote: > > Jason Merrill writes: >> I'm inclined to change the C++ FE to pass NULL_TREE instead until such >> time as someone cares. > > The sh backend will at least not choke on that ;-) Thus. commit 301b543f38b687fe5d90010b3c82ef2160362b1b Author: Jason Merrill Date: Wed Dec 6 14:33:32 2017 -0500 Correct argument to targetm.calls.promote_prototypes. * call.c (convert_for_arg_passing): Pass NULL_TREE to targetm.calls.promote_prototypes. (type_passed_as): Likewise. diff --git a/gcc/cp/call.c b/gcc/cp/call.c index e04626863af..bd7666d72bb 100644 --- a/gcc/cp/call.c +++ b/gcc/cp/call.c @@ -7350,7 +7350,7 @@ type_passed_as (tree type) /* There are no other pointers to this temporary. */ type = cp_build_qualified_type (type, TYPE_QUAL_RESTRICT); } - else if (targetm.calls.promote_prototypes (type) + else if (targetm.calls.promote_prototypes (NULL_TREE) && INTEGRAL_TYPE_P (type) && COMPLETE_TYPE_P (type) && tree_int_cst_lt (TYPE_SIZE (type), TYPE_SIZE (integer_type_node))) @@ -7390,7 +7390,7 @@ convert_for_arg_passing (tree type, tree val, tsubst_flags_t complain) /* Pass classes with copy ctors by invisible reference. */ else if (TREE_ADDRESSABLE (type)) val = build1 (ADDR_EXPR, build_reference_type (type), val); - else if (targetm.calls.promote_prototypes (type) + else if (targetm.calls.promote_prototypes (NULL_TREE) && INTEGRAL_TYPE_P (type) && COMPLETE_TYPE_P (type) && tree_int_cst_lt (TYPE_SIZE (type), TYPE_SIZE (integer_type_node)))
gcc-6-20171206 is now available
Snapshot gcc-6-20171206 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171206/ 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 255455 You'll find: gcc-6-20171206.tar.xzComplete GCC SHA256=d0a766414329660b4a46277deaa60ff3a467c808d1f644c05ecc7089bc7f003f SHA1=5891924b078c2817a2b2b85be1bba5ef7f87eff4 Diffs from 6-20171129 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: question about inlining
On 12/06/2017 12:11 PM, Richard Biener wrote:
On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor wrote:
While testing a libstdc++ patch that relies on inlining to
expose a GCC limitation I noticed that the same member function
of a class template is inlined into one function in the test but
not into the other, even though it is inlined into each if each
is compiled separately (i.e., in a file on its own).
I wasn't aware that inlining decisions made in one function could
affect those in another, or in the whole file. Is that expected?
And if yes, what's the rationale?
Here's a simplified test case. When compiled with -O2 or -O3
and either just -DFOO or just -DBAR, the call to vector::resize()
and all the functions called from it, including (crucially)
vector::_M_default_append, are inlined. But when compiled with
-DFOO -DBAR _M_default_append is not inlined. With a somewhat
more involved test case I've also seen the first call inlined
but not the second, which was also surprising to me.
There are unit and function growth limits that can be hit.
I see, thank you for reminding me.
Nothing brings the implications into sharp focus like two virtually
identical functions optimized differently as a result of exceeding
some size limit. It would make perfect sense to me if I were using
-Os but I can't help but wonder how useful this heuristic is at -O3.
It also makes me wonder if users are aware of how this impacts
their decisions to structure code. If adding a new function to
a file containing carefully optimized code can result in outlining
what was previously inlined, it's probably best to define one
function per file. I've seen C libraries laid out like that but
never a C++ program.
Martin
#include
void sink (std::vector&);
#if FOO
void foo (unsigned n)
{
std::vector a;
a.resize (n);
sink (a);
}
#endif
#if BAR
void bar (unsigned long n)
{
std::vector a;
a.resize (n);
sink (a);
}
#endif
Thanks
Martin
Re: question about inlining
On December 7, 2017 2:15:53 AM GMT+01:00, Martin Sebor wrote:
>On 12/06/2017 12:11 PM, Richard Biener wrote:
>> On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor
> wrote:
>>> While testing a libstdc++ patch that relies on inlining to
>>> expose a GCC limitation I noticed that the same member function
>>> of a class template is inlined into one function in the test but
>>> not into the other, even though it is inlined into each if each
>>> is compiled separately (i.e., in a file on its own).
>>>
>>> I wasn't aware that inlining decisions made in one function could
>>> affect those in another, or in the whole file. Is that expected?
>>> And if yes, what's the rationale?
>>>
>>> Here's a simplified test case. When compiled with -O2 or -O3
>>> and either just -DFOO or just -DBAR, the call to vector::resize()
>>> and all the functions called from it, including (crucially)
>>> vector::_M_default_append, are inlined. But when compiled with
>>> -DFOO -DBAR _M_default_append is not inlined. With a somewhat
>>> more involved test case I've also seen the first call inlined
>>> but not the second, which was also surprising to me.
>>
>> There are unit and function growth limits that can be hit.
>
>I see, thank you for reminding me.
>
>Nothing brings the implications into sharp focus like two virtually
>identical functions optimized differently as a result of exceeding
>some size limit. It would make perfect sense to me if I were using
>-Os but I can't help but wonder how useful this heuristic is at -O3.
Well. The inlining process is basically inlining functions sorted by priority
until the limits are hit (or nothing is profitable anymore). Without such limit
we'd blow size through the roof.
>It also makes me wonder if users are aware of how this impacts
>their decisions to structure code. If adding a new function to
>a file containing carefully optimized code can result in outlining
>what was previously inlined, it's probably best to define one
>function per file. I've seen C libraries laid out like that but
>never a C++ program.
>
>Martin
>
>>> #include
>>>
>>> void sink (std::vector&);
>>>
>>> #if FOO
>>> void foo (unsigned n)
>>> {
>>> std::vector a;
>>> a.resize (n);
>>> sink (a);
>>> }
>>> #endif
>>>
>>> #if BAR
>>> void bar (unsigned long n)
>>> {
>>> std::vector a;
>>> a.resize (n);
>>> sink (a);
>>> }
>>> #endif
>>>
>>> Thanks
>>> Martin
>>
