Re: [PATCH, rs6000] Clean up the option_mask defines (part 1)

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, May 26, 2022 at 09:40:18AM -0500, will schmidt wrote:
> On Thu, 2022-05-26 at 05:47 -0500, Segher Boessenkool wrote:
> > Yeah, the longer names are a bit annoying in any case.  We'll get
> > used
> > to it (if those long lines are fixed ;-) )
> 
> Agree.  I would not be opposed to somewhat shorter names for these, but
> naming is hard, and the long names are existing and sufficient for the
> moment.

The longer name is there no matter what we do...  uphill battle, I'd
rather not fight another one :-)

> > But, are those builtin masks still used at all?  Can't we just use
> > the
> > option masks where they still are?  The builtins do not use them
> > anymore :-)
> 
> They are still referenced in rs6000_builtin_mask_calculate() function,
> which is used to assign a value to rs6000_builtin_mask, which is still
> in use.

But we can easily use the OPTION_MASK things directly there.

> I had not yet dug deeper there, but agree it appears that is
> only used to print the current options, so could probably be safely
> eliminated.

And/or that, yes.

> I'll dig a bit more, but would handle that in a separate
> patch.

Can you please make a new patch series that just does everything?  This
is so much easier to handle for everyone, even you yourself :-)

First some small preparatory patches; then the long *boring* patches
that are the meat of the matter, but are completely mechanical
(formatting notwithstanding), so are easy to review; and then some more
small patches to do final cleanup.

So each patch will be easy to write, write a commit message for, write a
changelog for, and easy to review as well.  Long patches are no problem
at all if they are completely boring!


Segher