Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On 10/30/18 3:56 AM, Alexander Oblovatniy wrote: > Hello, > > I'd like to report a typo in description of > «__builtin_expect_with_probability»: > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins > > The description starts with "The built-in has same semantics as > *__builtin_expect_with_probability*", but it seems like *__builtin_expect* > should be there. Thanks for reporting the issue. It's fixed as r265615. Martin > > Thanks! >
Re: Suitable regression test for vectorizer patches?
On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke wrote: > > I want to submit some vectorizer patches, what would be a suitable > regression test? I am sure you have testcases, no? For new features please make them dg-do run ones by checking correctness. > Preferably some native or cross test that can run on an i7 x86_64 > GNU/Linux machine. You are probably talking about the need for specific HW features? We have dg-requires-effective-target FOO where IIRC there are ones that enable extra options for compilation (look for avx-runtime or so for example). Richard. > > To give an idea what code I'm patching, here are the patches I got so far: > > * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Recognize > unsigned dot product pattern. > > Allow widening multiply-add to be used for DOT_PROF_EXPR reductions. > * tree-vect-data-refs.c (vect_get_smallest_scalar_type): > Treat WIDEN_MULT_PLUS_EXPR like WIDEN_SUM_EXPR. > * tree-vect-loop.c (get_initial_def_for_reduction): Likewise. > Get VECTYPE from STMT_VINFO_VECTYPE. > (vect_determine_vectorization_factor): > Allow vcector size input/output mismatch for reduction. > (vect_analyze_scalar_cycles_1): When we find a phi for a reduction, > put the reduction statement into the phi's STMT_VINFO_RELATED_STMT. > * tree-vect-patterns.c (vect_pattern_recog_1): If DOT_PROD_EXPR > can't > be expanded directly, try to use WIDEN_MULT_PLUS_EXPR instead. > > Fix bug where a vectorizer reduction split (from > TARGET_VECTORIZE_SPLIT_REDUCTION) > would end up not being used. > * tree-vect-loop.c (vect_create_epilog_for_reduction): > If we split the reduction, use the result in Case 3 too.
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On 2018-10-30 09:29, Martin Liška wrote: > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote: >> Hello, >> >> I'd like to report a typo in description of >> «__builtin_expect_with_probability»: >> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins >> >> The description starts with "The built-in has same semantics as >> *__builtin_expect_with_probability*", but it seems like *__builtin_expect* >> should be there. > > Thanks for reporting the issue. It's fixed as r265615. Other issues around the same place: "expected probability (in percent)" seems to contradict "valid values are in inclusive range 0.0f and 1.0f". The prototype is listed as (long exp, long c, long probability) contradicting the prose "Last argument probability is of float type". So, should probability be an integer in [0, 100], or a float in [0, 1]? Rasmus
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes wrote:
>
> On 2018-10-30 09:29, Martin Liška wrote:
> > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> >> Hello,
> >>
> >> I'd like to report a typo in description of
> >> «__builtin_expect_with_probability»:
> >> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
> >>
> >> The description starts with "The built-in has same semantics as
> >> *__builtin_expect_with_probability*", but it seems like *__builtin_expect*
> >> should be there.
> >
> > Thanks for reporting the issue. It's fixed as r265615.
>
> Other issues around the same place: "expected probability (in percent)"
> seems to contradict "valid values are in inclusive range 0.0f and 1.0f".
> The prototype is listed as
>
> (long exp, long c, long probability)
The testcases added alongside the new built-in use float arguments,
but the actual definition of the built-in seems to use a long double.
What does "user can provide expected probability (in percent) for
value of @var{exp}" mean? What is the probability of the value of exp?
Don't you mean the probability that exp==c?
Also the grammar in the text needs several fixes.
>
> contradicting the prose "Last argument probability is of float type".
> So, should probability be an integer in [0, 100], or a float in [0, 1]?
>
> Rasmus
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On Tue, 30 Oct 2018 at 09:54, Jonathan Wakely wrote:
>
> On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes
> wrote:
> >
> > On 2018-10-30 09:29, Martin Liška wrote:
> > > On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> > >> Hello,
> > >>
> > >> I'd like to report a typo in description of
> > >> «__builtin_expect_with_probability»:
> > >> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
> > >>
> > >> The description starts with "The built-in has same semantics as
> > >> *__builtin_expect_with_probability*", but it seems like
> > >> *__builtin_expect*
> > >> should be there.
> > >
> > > Thanks for reporting the issue. It's fixed as r265615.
> >
> > Other issues around the same place: "expected probability (in percent)"
> > seems to contradict "valid values are in inclusive range 0.0f and 1.0f".
> > The prototype is listed as
> >
> > (long exp, long c, long probability)
>
> The testcases added alongside the new built-in use float arguments,
> but the actual definition of the built-in seems to use a long double.
>
> What does "user can provide expected probability (in percent) for
> value of @var{exp}" mean? What is the probability of the value of exp?
> Don't you mean the probability that exp==c?
>
> Also the grammar in the text needs several fixes.
Maybe something like:
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12025,12 +12025,12 @@ when testing pointer or floating-point values.
@end deftypefn
@deftypefn {Built-in Function} long __builtin_expect_with_probability
-(long @var{exp}, long @var{c}, long @var{probability})
+(long @var{exp}, long @var{c}, long double @var{probability})
-The built-in has same semantics as @code{__builtin_expect},
-but user can provide expected probability (in percent) for value of @var{exp}.
-Last argument @var{probability} is of float type and valid values
-are in inclusive range 0.0f and 1.0f.
+This function has the same semantics as @code{__builtin_expect},
+but the caller provides the expected probability that @var{exp} == @var{c}.
+The last argument, @var{probability}, is a floating point value in the
+range 0.0 to 1.0, inclusive.
@end deftypefn
@deftypefn {Built-in Function} void __builtin_trap (void)
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On 2018-10-30 10:54, Jonathan Wakely wrote: > On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes > wrote: >> >> On 2018-10-30 09:29, Martin Liška wrote: >>> On 10/30/18 3:56 AM, Alexander Oblovatniy wrote: Hello, I'd like to report a typo in description of «__builtin_expect_with_probability»: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins The description starts with "The built-in has same semantics as *__builtin_expect_with_probability*", but it seems like *__builtin_expect* should be there. >>> >>> Thanks for reporting the issue. It's fixed as r265615. >> >> Other issues around the same place: "expected probability (in percent)" >> seems to contradict "valid values are in inclusive range 0.0f and 1.0f". >> The prototype is listed as >> >> (long exp, long c, long probability) > > The testcases added alongside the new built-in use float arguments, > but the actual definition of the built-in seems to use a long double. In DEF_FUNCTION_TYPE_3 (BT_FN_LONG_LONG_LONG_DOUBLE, BT_LONG, BT_LONG, BT_LONG, BT_DOUBLE) doesn't the first LONG refer to the return type, so that the third argument just has type double? Other than that, your suggested update makes sense (provided it actually matches the implementation, which I can't verify).
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On Tue, Oct 30, 2018 at 11:11:00AM +0100, Rasmus Villemoes wrote: > In > > DEF_FUNCTION_TYPE_3 (BT_FN_LONG_LONG_LONG_DOUBLE, >BT_LONG, BT_LONG, BT_LONG, BT_DOUBLE) > > > doesn't the first LONG refer to the return type, so that the third > argument just has type double? Other than that, your suggested update Yes. A long double argument would be BT_LONGDOUBLE or written as _LONGDOUBLE in the name of the fn type. Jakub
clarification on the intent of X86_64 psABI vector return.
Hi,
For a processor that supports SSE, but not AVX.
the following code:
typedef int __attribute__((mode(QI))) qi;
typedef qi __attribute__((vector_size (32))) v32qi;
v32qi foo (int x)
{
v32qi y = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f',
'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
return y;
}
produces a warning " warning: AVX vector return without AVX enabled changes the
ABI [-Wpsabi]”.
so - the question is what is the resultant ABI in the changed case (since _m256
is supported for such processors)
Looking at the psABI v1.0
* pp24 Returning of Values
The returning of values is done according to the following algorithm:
• Classify the return type with the classification algorithm.
…
• If the class is SSE, the next available vector register of the
sequence %xmm0, %xmm1 is used.
• If the class is SSEUP, the eight byte is returned in the next
available eightbyte chunk of the last used vector register.
...
* classification algorithm : pp20
• Arguments of type __m256 are split into four eightbyte chunks. The
least significant one belongs to class SSE and all the others to class SSEUP.
• Arguments of type __m512 are split into eight eightbyte chunks. The
least significant one belongs to class SSE and all the others to class SSEUP.
* footnote on pp21
12 The post merger clean up described later ensures that, for the processors
that do not support the __m256 type, if the size of an object is larger than
two eightbytes and the first eightbyte is not SSE or any other eightbyte is not
SSEUP, it still has class MEMORY.
This in turn ensures that for processors that do support the __m256 type, if
the size of an object is four eightbytes and the first eightbyte is SSE and all
other eightbytes are SSEUP, it can be passed in a register. This also applies
to the __m512 type. That is for processors that support the __m512 type, if the
size of an object is eight eightbytes and the first eightbyte is SSE and all
other eightbytes are SSEUP, it can be passed in a register, otherwise, it will
be passed in memory.
---
However : the case where the processor does *not* support __m256 but the first
eightbyte *is* SSE and the following eighbytes *are* SSEUP is not clarified.
The intent for SSE seems clear - use a reg
The intent for following SSEUP is less clear.
Nevertheless, it seems to imply that the intent for processors with SSE that
the __m256 (and __m512) returns should be passed in xmm0:1(:3, maybe).
figure 3.4 pp23 does not clarify xmm* use for vector return at all - only
mentioning floating point.
= status
In any event, GCC passes the vec32 return in memory,
LLVM conversely passes it in xmm0:1 (at least for the versions I’ve tried).
which leads to an ABI discrepancy when GCC is used to build code on systems
based on LLVM.
Please could the X86 maintainers clarify the intent (and maybe consider
enhancing the footnote classification notes to make things clearer)?
- and then we can figure out how to deal with the systems that are already
implemented - and how to move forward.
(as an aside, in any event, it seems inefficient to pass through memory when at
least xmm0:1 are already set aside for return value use).
thanks
Iain
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On 10/30/18 10:58 AM, Jonathan Wakely wrote:
> On Tue, 30 Oct 2018 at 09:54, Jonathan Wakely wrote:
>>
>> On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes
>> wrote:
>>>
>>> On 2018-10-30 09:29, Martin Liška wrote:
On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> Hello,
>
> I'd like to report a typo in description of
> «__builtin_expect_with_probability»:
> https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
>
> The description starts with "The built-in has same semantics as
> *__builtin_expect_with_probability*", but it seems like *__builtin_expect*
> should be there.
Thanks for reporting the issue. It's fixed as r265615.
>>>
>>> Other issues around the same place: "expected probability (in percent)"
>>> seems to contradict "valid values are in inclusive range 0.0f and 1.0f".
>>> The prototype is listed as
>>>
>>> (long exp, long c, long probability)
>>
>> The testcases added alongside the new built-in use float arguments,
>> but the actual definition of the built-in seems to use a long double.
>>
>> What does "user can provide expected probability (in percent) for
>> value of @var{exp}" mean? What is the probability of the value of exp?
>> Don't you mean the probability that exp==c?
>>
>> Also the grammar in the text needs several fixes.
>
> Maybe something like:
>
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -12025,12 +12025,12 @@ when testing pointer or floating-point values.
> @end deftypefn
>
> @deftypefn {Built-in Function} long __builtin_expect_with_probability
> -(long @var{exp}, long @var{c}, long @var{probability})
> +(long @var{exp}, long @var{c}, long double @var{probability})
Hi.
Thanks for rewording!
I guess we should use:
s/long double/double
>
> -The built-in has same semantics as @code{__builtin_expect},
> -but user can provide expected probability (in percent) for value of
> @var{exp}.
> -Last argument @var{probability} is of float type and valid values
> -are in inclusive range 0.0f and 1.0f.
> +This function has the same semantics as @code{__builtin_expect},
> +but the caller provides the expected probability that @var{exp} == @var{c}.
> +The last argument, @var{probability}, is a floating point value in the
> +range 0.0 to 1.0, inclusive.
> @end deftypefn
That's definitely much better, can you pleas install it?
Thanks,
Martin
>
> @deftypefn {Built-in Function} void __builtin_trap (void)
>
Re: [wwwdocs] Typo in description of __builtin_expect_with_probability
On Tue, 30 Oct 2018 at 12:06, Martin Liška wrote:
>
> On 10/30/18 10:58 AM, Jonathan Wakely wrote:
> > On Tue, 30 Oct 2018 at 09:54, Jonathan Wakely wrote:
> >>
> >> On Tue, 30 Oct 2018 at 09:18, Rasmus Villemoes
> >> wrote:
> >>>
> >>> On 2018-10-30 09:29, Martin Liška wrote:
> On 10/30/18 3:56 AM, Alexander Oblovatniy wrote:
> > Hello,
> >
> > I'd like to report a typo in description of
> > «__builtin_expect_with_probability»:
> > https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
> >
> > The description starts with "The built-in has same semantics as
> > *__builtin_expect_with_probability*", but it seems like
> > *__builtin_expect*
> > should be there.
>
> Thanks for reporting the issue. It's fixed as r265615.
> >>>
> >>> Other issues around the same place: "expected probability (in percent)"
> >>> seems to contradict "valid values are in inclusive range 0.0f and 1.0f".
> >>> The prototype is listed as
> >>>
> >>> (long exp, long c, long probability)
> >>
> >> The testcases added alongside the new built-in use float arguments,
> >> but the actual definition of the built-in seems to use a long double.
> >>
> >> What does "user can provide expected probability (in percent) for
> >> value of @var{exp}" mean? What is the probability of the value of exp?
> >> Don't you mean the probability that exp==c?
> >>
> >> Also the grammar in the text needs several fixes.
> >
> > Maybe something like:
> >
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -12025,12 +12025,12 @@ when testing pointer or floating-point values.
> > @end deftypefn
> >
> > @deftypefn {Built-in Function} long __builtin_expect_with_probability
> > -(long @var{exp}, long @var{c}, long @var{probability})
> > +(long @var{exp}, long @var{c}, long double @var{probability})
>
> Hi.
>
> Thanks for rewording!
>
> I guess we should use:
> s/long double/double
Yup.
> >
> > -The built-in has same semantics as @code{__builtin_expect},
> > -but user can provide expected probability (in percent) for value of
> > @var{exp}.
> > -Last argument @var{probability} is of float type and valid values
> > -are in inclusive range 0.0f and 1.0f.
> > +This function has the same semantics as @code{__builtin_expect},
> > +but the caller provides the expected probability that @var{exp} == @var{c}.
> > +The last argument, @var{probability}, is a floating point value in the
> > +range 0.0 to 1.0, inclusive.
> > @end deftypefn
>
> That's definitely much better, can you pleas install it?
OK, will do - thanks everyone.
Re: clarification on the intent of X86_64 psABI vector return.
In Tue, Oct 30, 2018 at 4:28 AM Iain Sandoe wrote:
>
> Hi,
>
> For a processor that supports SSE, but not AVX.
>
> the following code:
>
> typedef int __attribute__((mode(QI))) qi;
> typedef qi __attribute__((vector_size (32))) v32qi;
>
> v32qi foo (int x)
> {
> v32qi y = {'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f',
> '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
> return y;
> }
>
> produces a warning " warning: AVX vector return without AVX enabled changes
> the ABI [-Wpsabi]”.
>
> so - the question is what is the resultant ABI in the changed case (since
> _m256 is supported for such processors)
>
>
>
> Looking at the psABI v1.0
>
> * pp24 Returning of Values
>
> The returning of values is done according to the following algorithm:
>
> • Classify the return type with the classification algorithm.
>
> …
> • If the class is SSE, the next available vector register of the
> sequence %xmm0, %xmm1 is used.
>
> • If the class is SSEUP, the eight byte is returned in the next
> available eightbyte chunk of the last used vector register.
>
> ...
>
> * classification algorithm : pp20
>
> • Arguments of type __m256 are split into four eightbyte chunks. The
> least significant one belongs to class SSE and all the others to class SSEUP.
>
> • Arguments of type __m512 are split into eight eightbyte chunks. The
> least significant one belongs to class SSE and all the others to class SSEUP.
>
> * footnote on pp21
>
> 12 The post merger clean up described later ensures that, for the processors
> that do not support the __m256 type, if the size of an object is larger than
> two eightbytes and the first eightbyte is not SSE or any other eightbyte is
> not SSEUP, it still has class MEMORY.
>
> This in turn ensures that for processors that do support the __m256 type, if
> the size of an object is four eightbytes and the first eightbyte is SSE and
> all other eightbytes are SSEUP, it can be passed in a register. This also
> applies to the __m512 type. That is for processors that support the __m512
> type, if the size of an object is eight eightbytes and the first eightbyte is
> SSE and all other eightbytes are SSEUP, it can be passed in a register,
> otherwise, it will be passed in memory.
>
> ---
>
> However : the case where the processor does *not* support __m256 but the
> first eightbyte *is* SSE and the following eighbytes *are* SSEUP is not
> clarified.
>
> The intent for SSE seems clear - use a reg
> The intent for following SSEUP is less clear.
>
> Nevertheless, it seems to imply that the intent for processors with SSE that
> the __m256 (and __m512) returns should be passed in xmm0:1(:3, maybe).
>
> figure 3.4 pp23 does not clarify xmm* use for vector return at all - only
> mentioning floating point.
>
> = status
>
> In any event, GCC passes the vec32 return in memory,
> LLVM conversely passes it in xmm0:1 (at least for the versions I’ve tried).
>
> which leads to an ABI discrepancy when GCC is used to build code on systems
> based on LLVM.
>
> Please could the X86 maintainers clarify the intent (and maybe consider
> enhancing the footnote classification notes to make things clearer)?
>
> - and then we can figure out how to deal with the systems that are already
> implemented - and how to move forward.
>
> (as an aside, in any event, it seems inefficient to pass through memory when
> at least xmm0:1 are already set aside for return value use).
Please open a bug to keep track.
Thanks.
--
H.J.
Re: clarification on the intent of X86_64 psABI vector return.
> On 30 Oct 2018, at 13:26, H.J. Lu wrote: > > In Tue, Oct 30, 2018 at 4:28 AM Iain Sandoe wrote: >> > > Please open a bug to keep track. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87812
