| Message ID | a2dae57f-d166-4c99-8edd-11784abdecab@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | x86emul/test: drop Xeon Phi S/G prefetch special case | expand |
On 16/10/2024 8:46 am, Jan Beulich wrote: > Another leftover from the dropping of Xeon Phi support. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
On Wed Oct 16, 2024 at 8:46 AM BST, Jan Beulich wrote: > Another leftover from the dropping of Xeon Phi support. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > Note: I'm deliberately not switching to use of the conditional operator, > as the form as is resulting now is what we'll want for APX (which is > where I noticed this small piece of dead logic). > > --- a/tools/tests/x86_emulator/evex-disp8.c > +++ b/tools/tests/x86_emulator/evex-disp8.c > @@ -911,10 +911,8 @@ static void test_one(const struct test * > n = test->scale == SC_vl ? vsz : esz; > if ( !sg ) > n += vsz; > - else if ( !strstr(test->mnemonic, "pf") ) > - n += esz; > else > - ++n; > + n += esz; Just making sure. This is leftover from 85191cf32180("x86: drop Xeon Phi support"), right? Dead code after the removal of the avx512pf group. If so, that sounds good. But (not having looking at the general logic), how come we go from ++n to "n += esz". It's all quite cryptic. > > for ( ; i < n; ++i ) > if ( accessed[i] != (sg ? (vsz / esz) >> (test->opc & 1 & !evex.w) Cheers, Alejandro
On 16.10.2024 12:34, Alejandro Vallejo wrote: > On Wed Oct 16, 2024 at 8:46 AM BST, Jan Beulich wrote: >> --- a/tools/tests/x86_emulator/evex-disp8.c >> +++ b/tools/tests/x86_emulator/evex-disp8.c >> @@ -911,10 +911,8 @@ static void test_one(const struct test * >> n = test->scale == SC_vl ? vsz : esz; >> if ( !sg ) >> n += vsz; >> - else if ( !strstr(test->mnemonic, "pf") ) >> - n += esz; >> else >> - ++n; >> + n += esz; > > Just making sure. This is leftover from 85191cf32180("x86: drop Xeon Phi > support"), right? Dead code after the removal of the avx512pf group. Yes. > If so, that sounds good. But (not having looking at the general logic), how > come we go from ++n to "n += esz". It's all quite cryptic. It's the (prior) if() portion we're keeping, and the "else" we're dropping. The if() checks for _no_ "pf" in the mnemonic. "Going from ++n to n+= esz" is merely an effect of how the change is being expressed as diff. Jan
On Wed Oct 16, 2024 at 11:54 AM BST, Jan Beulich wrote: > On 16.10.2024 12:34, Alejandro Vallejo wrote: > > On Wed Oct 16, 2024 at 8:46 AM BST, Jan Beulich wrote: > >> --- a/tools/tests/x86_emulator/evex-disp8.c > >> +++ b/tools/tests/x86_emulator/evex-disp8.c > >> @@ -911,10 +911,8 @@ static void test_one(const struct test * > >> n = test->scale == SC_vl ? vsz : esz; > >> if ( !sg ) > >> n += vsz; > >> - else if ( !strstr(test->mnemonic, "pf") ) > >> - n += esz; > >> else > >> - ++n; > >> + n += esz; > > > > Just making sure. This is leftover from 85191cf32180("x86: drop Xeon Phi > > support"), right? Dead code after the removal of the avx512pf group. > > Yes. > > > If so, that sounds good. But (not having looking at the general logic), how > > come we go from ++n to "n += esz". It's all quite cryptic. > > It's the (prior) if() portion we're keeping, and the "else" we're dropping. > The if() checks for _no_ "pf" in the mnemonic. "Going from ++n to n+= esz" > is merely an effect of how the change is being expressed as diff. > > Jan Bah, misremembered strstr() being used like strcmp() on match, but of course that makes no sense with the substring being returned. Thanks for spelling it out :) Cheers, Alejandro
--- a/tools/tests/x86_emulator/evex-disp8.c +++ b/tools/tests/x86_emulator/evex-disp8.c @@ -911,10 +911,8 @@ static void test_one(const struct test * n = test->scale == SC_vl ? vsz : esz; if ( !sg ) n += vsz; - else if ( !strstr(test->mnemonic, "pf") ) - n += esz; else - ++n; + n += esz; for ( ; i < n; ++i ) if ( accessed[i] != (sg ? (vsz / esz) >> (test->opc & 1 & !evex.w)
Another leftover from the dropping of Xeon Phi support. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- Note: I'm deliberately not switching to use of the conditional operator, as the form as is resulting now is what we'll want for APX (which is where I noticed this small piece of dead logic).