> Let me know if you believe this is a good approach? I've ran regression
> tests and this hasn't broken anything so far...
Small regression in Ada though, probably a missing guard somewhere:
=== gnat tests ===
Running target unix
FAIL: gnat.dg/loop_optimization23.adb 3 blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107226
On Wed, Oct 12, 2022 at 9:55 AM Hongtao Liu wrote:
>
> This commit failed tests
>
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c
This commit failed tests
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr92645.c scan-tree-dump-times optimized "vec_unpack_" 4
FAIL:
Hi,
Whilst running a bootstrap with extra options to force bitfield
vectorization '-O2 -ftree-vectorize -ftree-loop-if-convert
-fno-vect-cost-model' I ran into an ICE in vect-patterns where a
bit_field_ref had a container that wasn't INTEGRAL_TYPE and had a
E_BLKmode, which meant we failed
On Wed, Sep 28, 2022 at 7:32 PM Andre Vieira (lists) via Gcc-patches
wrote:
>
> Made the change and also created the ChangeLogs.
OK if bootstrap / testing succeeds.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * tree-if-conv.cc (if_convertible_loop_p_1): Move ordering of
> loop bb's from
Made the change and also created the ChangeLogs.
gcc/ChangeLog:
* tree-if-conv.cc (if_convertible_loop_p_1): Move ordering of
loop bb's from here...
(tree_if_conversion): ... to here. Also call bitfield lowering
when appropriate.
(version_loop_for_if_conversion):
On 27/09/2022 13:34, Richard Biener wrote:
On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:
On 08/09/2022 12:51, Richard Biener wrote:
I'm curious, why the push to redundant_ssa_names? That could use
a comment ...
So I purposefully left a #if 0 #else #endif in there so you can see the two
On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:
>
> On 08/09/2022 12:51, Richard Biener wrote:
> >
> > I'm curious, why the push to redundant_ssa_names? That could use
> > a comment ...
> So I purposefully left a #if 0 #else #endif in there so you can see the two
> options. But the reason I
On 08/09/2022 12:51, Richard Biener wrote:
I'm curious, why the push to redundant_ssa_names? That could use
a comment ...
So I purposefully left a #if 0 #else #endif in there so you can see the
two options. But the reason I used redundant_ssa_names is because ifcvt
seems to use that as a
On Thu, 25 Aug 2022, Andre Vieira (lists) wrote:
>
> On 17/08/2022 13:49, Richard Biener wrote:
> > Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
> > of the representative from DECL_FIELD_BIT_OFFSET of the original bitfield
> > access - that's the offset within the
Ping.
On 25/08/2022 10:09, Andre Vieira (lists) via Gcc-patches wrote:
On 17/08/2022 13:49, Richard Biener wrote:
Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
of the representative from DECL_FIELD_BIT_OFFSET of the original
bitfield
access - that's the offset
On 17/08/2022 13:49, Richard Biener wrote:
Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
of the representative from DECL_FIELD_BIT_OFFSET of the original bitfield
access - that's the offset within the representative (by construction
both fields share DECL_FIELD_OFFSET).
On Tue, 16 Aug 2022, Andre Vieira (lists) wrote:
> Hi,
>
> New version of the patch attached, but haven't recreated the ChangeLog yet,
> just waiting to see if this is what you had in mind. See also some replies to
> your comments in-line below:
>
> On 09/08/2022 15:34, Richard Biener wrote:
>
Hi,
New version of the patch attached, but haven't recreated the ChangeLog
yet, just waiting to see if this is what you had in mind. See also some
replies to your comments in-line below:
On 09/08/2022 15:34, Richard Biener wrote:
@@ -2998,7 +3013,7 @@ ifcvt_split_critical_edges (class loop
On Mon, 8 Aug 2022, Andre Vieira (lists) wrote:
> Hi,
>
> So I've changed the approach from the RFC as suggested, moving the bitfield
> lowering to the if-convert pass.
>
> So to reiterate, ifcvt will lower COMPONENT_REF's with DECL_BIT_FIELD field's
> to either BIT_FIELD_REF if they are reads
Hi,
So I've changed the approach from the RFC as suggested, moving the
bitfield lowering to the if-convert pass.
So to reiterate, ifcvt will lower COMPONENT_REF's with DECL_BIT_FIELD
field's to either BIT_FIELD_REF if they are reads or BIT_INSERT_EXPR if
they are writes, using loads and
On Mon, 1 Aug 2022, Andre Vieira (lists) wrote:
>
> On 29/07/2022 11:52, Richard Biener wrote:
> > On Fri, 29 Jul 2022, Jakub Jelinek wrote:
> >
> >> On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via
> >> Gcc-patches wrote:
> >>> The 'only on the vectorized code path' remains
On 29/07/2022 11:52, Richard Biener wrote:
On Fri, 29 Jul 2022, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vectorized code
On 29/07/2022 11:31, Jakub Jelinek wrote:
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
The 'only on the vectorized code path' remains the same though as vect_recog
also only happens on the vectorized code path right?
if conversion (in some cases)
On Fri, 29 Jul 2022, Jakub Jelinek wrote:
> On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via
> Gcc-patches wrote:
> > The 'only on the vectorized code path' remains the same though as vect_recog
> > also only happens on the vectorized code path right?
>
> if conversion (in
On Fri, Jul 29, 2022 at 09:57:29AM +0100, Andre Vieira (lists) via Gcc-patches
wrote:
> The 'only on the vectorized code path' remains the same though as vect_recog
> also only happens on the vectorized code path right?
if conversion (in some cases) duplicates a loop and guards one copy with
an
On Fri, 29 Jul 2022, Andre Vieira (lists) wrote:
> Hi Richard,
>
> Thanks for the review, I don't completely understand all of the below, so I
> added some extra questions to help me understand :)
>
> On 27/07/2022 12:37, Richard Biener wrote:
> > On Tue, 26 Jul 2022, Andre Vieira (lists)
Hi Richard,
Thanks for the review, I don't completely understand all of the below,
so I added some extra questions to help me understand :)
On 27/07/2022 12:37, Richard Biener wrote:
On Tue, 26 Jul 2022, Andre Vieira (lists) wrote:
I don't think this is a good approach for what you gain and
On Tue, 26 Jul 2022, Andre Vieira (lists) wrote:
> Hi,
>
> This is a RFC for my prototype for bitfield read vectorization. This patch
> enables bit-field read vectorization by removing the rejection of bit-field
> read's during DR analysis and by adding two vect patterns. The first one
>
Hi,
This is a RFC for my prototype for bitfield read vectorization. This
patch enables bit-field read vectorization by removing the rejection of
bit-field read's during DR analysis and by adding two vect patterns. The
first one transforms TREE_COMPONENT's with BIT_FIELD_DECL's into
25 matches
Mail list logo
