Re: [PATCH] LoongArch: document -m[no-]explicit-relocs

[Lulu Cheng <chenglulu@loongson.cn>]

在 2022/7/27 下午3:21, WANG Xuerui 写道:
> Hi,
>
> On 2022/7/27 15:06, Xi Ruoyao wrote:
>> Document newly introduced -m[no-]explicit-relocs options.  Ok for trunk?
>>
>> -- >8 --
>>
>> gcc/ChangeLog:
>>
>>     * doc/invoke.texi: Document -m[no-]explicit-relocs for
>>     LoongArch.
>> ---
>>   gcc/doc/invoke.texi | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 9a3f2d14c5a..04418f80428 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -24939,6 +24939,18 @@ global symbol: The data got table must be 
>> within +/-8EiB addressing space.
>>   @end itemize
>>   @end table
>>   The default code model is @code{normal}.
>> +
>> +@item -mexplicit-relocs
>> +@itemx -mno-explicit-relocs
>> +@opindex mexplicit-relocs
>> +@opindex mno-explicit-relocs
>> +Generate (do not generate) explicit symbol relocations instead of
>> +assembler macros.  Using explicit relocations can improve code 
>> generation.
>> +GCC detects the capaiblities of the assembler when it is built and sets
>> +the default to @code{-mexplicit-relocs} if the assembler supports the
>> +syntax for explicit specification of relocations, and
>> +@code{-mno-explicit-relocs} otherwise.  This option is mostly useful 
>> for
>> +debugging or using an assembler different from build-time.
>
> Some text massaging, along with some shameful copying from other 
> (read: RISC-V) -mexplicit-relocs docs...
>
> "Use or do not use assembler relocation operators when dealing with 
> symbolic addresses. The alternative is to use assembler macros 
> instead, which may limit optimization.
>
> The default value for the option is determined during GCC build-time 
> by detecting corresponding assembler support: @code{-mexplicit-relocs} 
> if said support is present, @code{-mno-explicit-relocs} otherwise. 
> This option is mostly useful for debugging, or interoperation with 
> assemblers different from the build-time one."
>
> What do you think?
>
>>   @end table
>>     @node M32C Options

I agree with wangxuerui's idea.

The same parameter and the same description information can reduce the 
user's time to learn how to use this parameter.