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): Adapt to enable loop 
versioning when we only need
         to lower bitfields.
         (ifcvt_split_critical_edges): Relax condition of expected loop 
form as this is checked earlier.
         (get_bitfield_rep): New function.
         (lower_bitfield): Likewise.
         (bitfields_to_lower_p): Likewise.
         (need_to_lower_bitfields): New global boolean.
         (need_to_ifcvt): Likewise.
         * tree-vect-data-refs.cc (vect_find_stmt_data_reference): 
Improve diagnostic message.
         * tree-vect-patterns.cc (vect_recog_temp_ssa_var): Add default 
value for last parameter.
         (vect_recog_bitfield_ref_pattern): New.
         (vect_recog_bit_insert_pattern): New.

gcc/testsuite/ChangeLog:

         * gcc.dg/vect/vect-bitfield-read-1.c: New test.
         * gcc.dg/vect/vect-bitfield-read-2.c: New test.
         * gcc.dg/vect/vect-bitfield-read-3.c: New test.
         * gcc.dg/vect/vect-bitfield-read-4.c: New test.
         * gcc.dg/vect/vect-bitfield-read-5.c: New test.
         * gcc.dg/vect/vect-bitfield-read-6.c: New test.
         * gcc.dg/vect/vect-bitfield-write-1.c: New test.
         * gcc.dg/vect/vect-bitfield-write-2.c: New test.
         * gcc.dg/vect/vect-bitfield-write-3.c: New test.
         * gcc.dg/vect/vect-bitfield-write-4.c: New test.
         * gcc.dg/vect/vect-bitfield-write-5.c: New test.

On 28/09/2022 10:43, Andre Vieira (lists) via Gcc-patches wrote:
>
> 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
>>> options. But the reason I used redundant_ssa_names is because ifcvt 
>>> seems to
>>> use that as a container for all pairs of (old, new) ssa names to 
>>> replace
>>> later. So I just piggy backed on that. I don't know if there's a 
>>> specific
>>> reason they do the replacement at the end? Maybe some ordering 
>>> issue? Either
>>> way both adding it to redundant_ssa_names or doing the replacement 
>>> inline work
>>> for the bitfield lowering (or work in my testing at least).
>> Possibly because we (in the past?) inserted/copied stuff based on
>> predicates generated at analysis time after we decide to elide something
>> so we need to watch for later appearing uses.  But who knows ... my mind
>> fails me here.
>>
>> If it works to replace uses immediately please do so.  But now
>> I wonder why we need this - the value shouldn't change so you
>> should get away with re-using the existing SSA name for the final value?
>
> Yeah... good point. A quick change and minor testing seems to agree. 
> I'm sure I had a good reason to do it initially ;)
>
> I'll run a full-regression on this change to make sure I didn't miss 
> anything.
>