Messages in this thread | | | Date | Fri, 15 Sep 2023 09:51:06 +0200 | From | Peter Zijlstra <> | Subject | Re: [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 ....
| |