lkml.org 
[lkml]   [2023]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 10/11] x86/alternatives: Simplify ALTERNATIVE_n()
On Fri, Sep 15, 2023 at 09:46:47AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 13, 2023 at 04:38:47PM +0200, Borislav Petkov wrote:
>
> > [ bp: Make labels unique and thus all sizing use unambiguous labels.
> > Add more info. ]
>
> > +#define __ALTERNATIVE(oldinstr, newinstr, ft_flags, n) \
> > + OLDINSTR(oldinstr, n) \
> > + ALTINSTR_ENTRY(ft_flags) \
> > + ALTINSTR_REPLACEMENT(newinstr)
>
> > +#define ALTERNATIVE_2(oldinst, newinst1, flag1, newinst2, flag2) \
> > + __ALTERNATIVE(ALTERNATIVE(oldinst, newinst1, flag1), \
> > + newinst2, flag2, 1)
>
> > +#define ALTERNATIVE_3(oldinst, newinst1, flag1, newinst2, flag2, \
> > + newinst3, flag3) \
> > + __ALTERNATIVE(ALTERNATIVE_2(oldinst, newinst1, flag1, newinst2, flag2), \
> > + newinst3, flag3, 2)
>
>
> So I see what you did with that @n argument, but urgh, do we really need
> this? I mean, it just makes things harder to use and it doesn't actually
> fix anything.. :/

That is, if we can magic this using __COUNTER__ without a user interface
penalty, then sure. But the last time I tried that I failed utterly and
ended up with labels like:

.Lalt_old___COUNTER__:

no matter how many layers of CPP macro eval I stuck in it. So clearly I
wasn't having a good day ....

\
 
 \ /
  Last update: 2023-09-15 09:52    [W:0.119 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site