On Tue, 29 Aug 2023, Andrew Pinski wrote:
> Hi,
> I was reading some code in tree-vect-patterns.cc and I came across
> vect_recog_mixed_size_cond_pattern . The code tries to handle
> comparisons from COND_EXPR but that cannot happen any more (after
> r13-707-g68e0063397ba82).
> Should this code
On Wed, Aug 30, 2023 at 12:26 AM Richard Biener wrote:
>
> On Tue, 29 Aug 2023, Andrew Pinski wrote:
>
> > Hi,
> > I was reading some code in tree-vect-patterns.cc and I came across
> > vect_recog_mixed_size_cond_pattern . The code tries to handle
> > comparisons from COND_EXPR but that cannot h
Hi, I start to enable "vect" testsuite for RISC-V.
I have a question when analyzing the 'wrapv-vect-reduc-dot-s8b.c'
It failed at:
FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
"vect_recog_dot_prod_pattern: detected" 1
FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tre
On Wed, 30 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, I start to enable "vect" testsuite for RISC-V.
>
> I have a question when analyzing the 'wrapv-vect-reduc-dot-s8b.c'
> It failed at:
> FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vect_recog_dot_prod_pattern: det
Thanks Richi.
>> both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
Sorry I made a mistake here. They are not the same nunits.
wrapv-vect-reduc-dot-s8b.c:29:14: note: get vectype for scalar type: short
int
wrapv-vect-reduc-dot-s8b.c:29:14: note: vectype: vector([8,8]) s
>> To fix it, is it necessary to support 'vec_unpack' ?
>
> both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
> ties its hands by choosing vector types early and based on the number
> of incoming/outgoing vectors it chooses one or the other method.
>
> More precise dumping w
I am wondering whether we do have some situations that
vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be beneficial for RVV ?
I have ever met some situation that vec_unpack can be beneficial when working
on SELECT_VL but I don't which case
juzhe.zh...@rivai.ai
From: Robin Dapp
Da
On Wed, 30 Aug 2023, Robin Dapp wrote:
> >> To fix it, is it necessary to support 'vec_unpack' ?
> >
> > both same units would be sext, not vec_unpacks_{lo,hi} - the vectorizer
> > ties its hands by choosing vector types early and based on the number
> > of incoming/outgoing vectors it chooses on
On Wed, 30 Aug 2023, juzhe.zh...@rivai.ai wrote:
> I am wondering whether we do have some situations that
> vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be beneficial for RVV ?
> I have ever met some situation that vec_unpack can be beneficial when working
> on SELECT_VL but I don't wh
> it's target dependent what we choose first so it's going to be
> a bit difficult to adjust testcases like this (and it looks like
> a testsuite issue). I think for this specific testcase changing
> scan-tree-dump-times to scan-tree-dump is reasonable. Note we
> really want to check that for the
>> I am wondering whether we do have some situations that
>> vec_pack/vec_unpack/vec_widen_xxx/dot_prod pattern can be
>> beneficial for RVV ? I have ever met some situation that vec_unpack
>> can be beneficial when working on SELECT_VL but I don't which
>> case
>
> With fixed size vectors y
Hi David,
I’m seeing the following failures on building GCC with Apple’s clang:
> /Users/fx/devel/gcc/gcc-repo-write/gcc/analyzer/region-model.cc:3426:16:
> error: unexpected type name 'byte_size_t': expected expression
>std::max (bytes.m_size_in_bytes,
>
On Wed, Aug 30, 2023 at 11:10:57AM +0200, FX Coudert via Gcc wrote:
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not
> available because is not included. The following patch fixes the
> build for me:
>
> diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/regio
> the dump-scans. Can we do sth like
> "vect_recog_dot_prod_pattern: detected\n(!FAILED)*SUCCEEDED", thus
> after the dot-prod pattern dumping allow arbitrary stuff but _not_
> a "failed" and then require a "succeeded"?
It took some fighting with tcl syntax until I arrived at the regex
pattern be
> std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573, are not
> available because is not included.
I originally thought this was only seen in cross-compilers, but it actually
broke bootstrap on darwin.
Attached patch restores it, OK to commit?
FX
0001-Analyzer-include-algori
On Wed, 2023-08-30 at 23:24 +0200, FX Coudert wrote:
> > std::max and std::min, introduced by d99d73c77d1e and 2bad0eeb5573,
> > are not available because is not included.
>
> I originally thought this was only seen in cross-compilers, but it
> actually broke bootstrap on darwin.
> Attached patch
On Tue, Aug 29, 2023 at 5:14 PM David Malcolm wrote:
>
> On Tue, 2023-08-29 at 13:28 -0400, Eric Feng wrote:
> > Additionally, by using the old model and the pointer per your
> > suggestion,
> > we are able to find the representative tree and emit a more accurate
> > diagnostic!
> >
> > rc3.c:23:1
Hi, Richard and Richi.
Currently, we are statically returning vectorization factor in
'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'
according to compile option.
For example:
void
foo (int32_t *__restrict a, int32_t *__restrict b, int n)
{
for (int i = 0; i < n; i++)
a[i] = a[i] + b[i];
}
with --
18 matches
Mail list logo
