Re: Xen 4.20 release schedule

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/11/2024 1:47 pm, Frediano Ziglio wrote:
> On Thu, Nov 21, 2024 at 1:40 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>> On 21.11.2024 13:53, Frediano Ziglio wrote:
>>> On Wed, Oct 30, 2024 at 1:25 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>> wrote:
>>>> On 21/10/2024 1:02 pm, oleksii.kurochko@xxxxxxxxx wrote:
>>>>> Hello everyone,
>>>>>
>>>>> As there were no objections to the proposed release schedule
>>>>> (https://lore.kernel.org/xen-devel/CAMacjJxEi6PThwH2=NwG3He8eQn39aiaxZCw3bQF7i4YcmjuNw@xxxxxxxxxxxxxx/
>>>>> ), I've updated the wiki with the schedule for Xen 4.20 release
>>>>> (https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes), and
>>>>> it is now accessible from
>>>>> https://xenbits.xen.org/docs/unstable-staging/support-matrix.html.
>>>> I have a blocker to raise (against myself...) and no good idea of how to
>>>> proceed.
>>>>
>>>> The for_each_bit work has a unexpected bug.
>>>>
>>>>     for_each_bit ( ... )
>>>>     {
>>>>         if ( ... )
>>>>             break;
>>>>     }
>>>>
>>>> will fall into an infinite loop.  This is caused by for_each_bit()
>>>> hiding a double for() loop, in order to declare two scope-local
>>>> variables of different types.
>>>>
>>>> The two variables are one copy of the source expression (really quite
>>>> important to keep), and one unsigned int iterator (improved optimisation
>>>> capability by not using a wider-scope variable).
>>>>
>>>> Options are (off the top of my head)
>>>>
>>>> 1) Always take the iterator from outer scope
>>>> 2) Iterator always the same type as the source expression
>>>> 3) Figure out some way of expressing "once" in the outer loop
>>>>
>>>> Or anything else that I've missed.
>>>>
>>>> ~Andrew
>>>>
>>> Something like
>>>
>>> #define for_each_set_bit(iter, val)                     \
>>>     for ( typeof(val) __v = (val), __c=1; __c; __c=0)   \
>>>         for ( unsigned int (iter);                      \
>>>               __v && ((iter) = ffs_g(__v) - 1, true);   \
>>>               __v &= __v - 1 )
>>>
>>> ?

Yes, that was the option 3 I was thinking about, although I'd not got as
far as doing the thinking bit yet.

>> Hmm, right, but then we don't even need a 2nd variable, do we?
>>
>> #define for_each_set_bit(iter, val)                     \
>>     for ( typeof(val) __v = (val); __v; __v = 0 )       \
>>         for ( unsigned int (iter);                      \
>>               __v && ((iter) = ffs_g(__v) - 1, true);   \
>>               __v &= __v - 1 )

This does look like a better option.

>>
>> Jan
> In theory it should work too, not sure if the variable aliasing would
> compromise the assembly output. We depend on the compiler doing some
> optimizations.

We already depend on some optimisation to get rid of the double loop
(both -O2 and -O1 cope).

I'll double check the result here too.

~Andrew