[PATCH] x86: actually implement .noopt

[Jan Beulich]

On 08.01.2024 02:18, Fangrui Song wrote:
> On Fri, Jan 5, 2024 at 12:31 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> For quite some time we've had support for -O command line options. With
>> that ignoring at least .noopt isn't really a good idea.
>>
>> Re-purpose the optimize-3 test for testing this directive's effect as
>> well.
>>
>> As to the doc addition - this uses the same text as is there for the
>> {nooptimize} pseudo-prefix, despite me not being convinced of the "size"
>> part being fully accurate there (and hence also here).
>> ---
>> I haven't been able to find any applicable documentation for other
>> (perhaps legacy) assemblers' support of .noopt (and .optim). An option
>> to also handle .optim would be to
>> - restore previously saved settings (if optimization was enabled on the
>>   command line),
>> - enable a pre-determined level of optimization if optimization was not
>>   enabled on the command line.
>> Thoughts?
> 
> Interesting. This is from
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b6f8c7c45229a8a5405079e586bfbaad396d2cbe
> ("x86: Add -O[2|s] assembler command-line options").

I'm confused by your reply: How is the above related (other than being,
as stated, the reason for wanting to no longer ignore .noopt)?

> If push/pop are to be added, it seems clear if push/pop/setting use
> the same directive like .noopt push, .noopt pop, .noopt optimize,
> .noopt nooptimize, but the negative directive name now causes
> confusion.
> In addition, "opt" option means "option" (mips/riscv have .option).
> Perhaps switch to a more meaningful directive name?

Well, did you look at, in particular, ...

>> @@ -1231,7 +1232,7 @@ const pseudo_typeS md_pseudo_table[] =
>>    {"value", cons, 2},
>>    {"slong", signed_cons, 4},
>>    {"insn", s_insn, 0},
>> -  {"noopt", s_ignore, 0},
>> +  {"noopt", s_noopt, 0},
>>    {"optim", s_ignore, 0},
>>    {"code16gcc", set_16bit_gcc_code_flag, CODE_16BIT},
>>    {"code16", set_code_flag, CODE_16BIT},

... this hunk? The respective "positive" directive is .optim. Yet
implementing that without knowing its origin seemed less desirable to
me. If we were entirely free, I certainly would agree with having
push/pop forms.

Jan