On Tue, Jun 04, 2024 at 09:50:04AM +0200, Richard Biener wrote:
> On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc
> wrote:
> >
> > Hi all,
> >
> > Is there some sort of guarantee that the unused part of a partial vector has
> > all bits set t
On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc
wrote:
>
> Hi all,
>
> Is there some sort of guarantee that the unused part of a partial vector has
> all bits set to zero?
>
> The question came up while implementing an insn for mode V2SF on s390
> whe
Hi all,
Is there some sort of guarantee that the unused part of a partial vector has
all bits set to zero?
The question came up while implementing an insn for mode V2SF on s390
where only half of the hard register would be utilized. The final
machine instruction, however, would make use
https://gcc.gnu.org/g:704b15e277a8792ac4cd6008ee08bec4b047a3e6
commit r13-8684-g704b15e277a8792ac4cd6008ee08bec4b047a3e6
Author: Richard Biener
Date: Wed Apr 17 10:40:04 2024 +0200
tree-optimization/114749 - reset partial vector decision for no-SLP retry
The following makes sure
https://gcc.gnu.org/g:bf2b5231312e1cea45732cb8df6ffa2b2c9115b6
commit r14-10005-gbf2b5231312e1cea45732cb8df6ffa2b2c9115b6
Author: Richard Biener
Date: Wed Apr 17 10:40:04 2024 +0200
tree-optimization/114749 - reset partial vector decision for no-SLP retry
The following makes sure
The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P
to its default of false when re-trying without SLP as otherwise
analysis may run into bogus asserts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree-optimization/114749
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111859
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111859
--- Comment #1 from Hongtao.liu ---
Could be reproduced with:
tar zxvf 521.tar.gz
cd 521
gfortran module_advect_em.fppizedi.f90 -S -O2 -march=cascadelake --param
vect-partial-vector-usage=2 -std=legacy -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111859
Bug ID: 111859
Summary: 521.wrf_r build failure with -O2 -march=cascadelake
--param vect-partial-vector-usage=2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
nux-gnu. This should
> avoid regressing 525.x264_r with partial vector epilogues and
> instead improves it by 25% with -march=znver4 (need to re-check
> that, that was true with some earlier attempt).
>
> This falls short of enabling cost comparison in the x86 backend
> which I also
and matches for
the problematic case, forcing a high cost to make us try a
smaller vector size.
Bootstrapped and tested on x86_64-unknown-linux-gnu. This should
avoid regressing 525.x264_r with partial vector epilogues and
instead improves it by 25% with -march=znver4 (need to re-check
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > Currently vect_determine_partial_vectors_and_peeling will decide
> > to apply fully masking to the main loop despite
> > --param vect-partial-vector-usage=1 when the currently ana
Richard Biener via Gcc-patches writes:
> Currently vect_determine_partial_vectors_and_peeling will decide
> to apply fully masking to the main loop despite
> --param vect-partial-vector-usage=1 when the currently analyzed
> vector mode results in a vectorization factor that's b
Currently vect_determine_partial_vectors_and_peeling will decide
to apply fully masking to the main loop despite
--param vect-partial-vector-usage=1 when the currently analyzed
vector mode results in a vectorization factor that's bigger
than the number of scalar iterations. That's undesirable
Add V8QImode and V4QImode vector shift patterns that call into
ix86_expand_vecop_qihi_partial. Generate special sequences
for constant count operands.
The patch regresses g++.dg/pr91838.C - as explained in PR91838, the
test returns different results, depending on whether V8QImode shift
pattern
QImode partial vector multiplications and shifts can be implemented using
their HImode counterparts. Add infrastructure to handle V8QImode and
V4QImode vectors by extending (interleaving) their input operands to
V8HImode, performing V8HImode operation and truncating output back to
the original
) but we don't enable partial vector on it by
default. It should be considered as not supporting partial vector by
default. This fix is to make the flag supports_partial_vectors check
param_vect_partial_vector_usage accordingly.
This was approved by Richard in the PR, thanks Richard and Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103094
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:73c3dacef9a30d7d66918606a97c496c71289f1b
commit r12-5998-g73c3dacef9a30d7d66918606a97c496c71289f1b
Author: Richard Sandiford
Priority|P3 |P1
Summary|[12 Regression] Incorrect |[12 Regression] AAPCS for
|codegen from uint8x8x2_t|new partial vector mode
|function arguments |types (e.g. V2x8QI
On Thu, Jul 15, 2021 at 8:33 PM Richard Biener wrote:
>
> The following defaults --param vect-partial-vector-usage to zero
> for x86_64 matching existing behavior where support for this
> is not present.
>
> OK for trunk?
>
Ok.
> Thanks,
> Richard/
>
The following defaults --param vect-partial-vector-usage to zero
for x86_64 matching existing behavior where support for this
is not present.
OK for trunk?
Thanks,
Richard/
2021-07-15 Richard Biener
* config/i386/i386-options.c (ix86_option_override_internal): Set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
Bug #: 51033
Summary: Partial vector extension support
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-08
16:42:25 UTC ---
Hmm, I thought we did the C++ extension mainly for the SPU stuff and think
that C++ language features are powerful enough to implement those extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #2 from Marc Glisse marc.glisse at normalesup dot org 2011-11-08
17:13:39 UTC ---
It's probably doable, but it sounds like you have to duplicate all the logic
that is currently in the various backends (and some in the C front-end and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-11-08
22:03:12 UTC ---
All vector support should also be in the C++ front-end. Can you give an
example of something which does not work? Templates with vectors work already
too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033
--- Comment #4 from Marc Glisse marc.glisse at normalesup dot org 2011-11-08
22:18:33 UTC ---
(In reply to comment #3)
All vector support should also be in the C++ front-end. Can you give an
example of something which does not work? Templates
27 matches
Mail list logo
