Re: [PATCH 2/2] RISC-V: adjust logic to avoid register name symbols

[Nelson Chu <nelson@rivosinc.com>]

Thanks for the detailed clarify :-)

A quick update, I just use riscv-gnu-toolchain to build a linux toolchain with,
gcc (releases/gcc-12.2.0) + binutils (master + these two patches) +
glibc (release/2.37/master),
and then I get some unexpected errors from gcc testsuite, which won't
occurred without these patches.

               ========= Summary of gcc testsuite =========
                            | # of unexpected case / # of unique unexpected case
                            |          gcc |          g++ |     gfortran |
     rv64gc/  lp64d/ medlow |  347 /    62 |   29 /     9 |    0 /     0 |

I haven't tested the elf regressions, and the whole linux regression,
but it seems that there are some unexpected situations that we have
not considered in this patch.

Reproduce commands,
1. git clone https://github.com/riscv-collab/riscv-gnu-toolchain.git --recursive
2. need to install some tools before build,
https://github.com/riscv-collab/riscv-gnu-toolchain#prerequisites
3. git checkout branches of gcc, binutils and glibc to the branches
mentioned above
4. cd <patch-to-build-folder>
5. <patch-to-riscv-gnu-toolchain>configure
--prefix=<patch-to-build-folder>build-install --with-arch=rv64gc
6. make report-gcc-linux -j32

Thanks
Nelson

On Wed, Feb 15, 2023 at 4:03 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.02.2023 04:09, Nelson Chu wrote:
> > Though the logic becomes kind of complicated to me, you are more
> > familiar with other targets than me, so maybe this is the right way to
> > do it.  Basically, the logic looks correct and fine to me, but I still
> > need to run regressions in case of an accident.  Just make sure that -
> > 1. The deferred_sym_rootP are the symbols that have the same names as
> > GPR (or FPR, VPR in the future maybe), but we still need to add them
> > into the symbol table?
>
> Yes, with "may" inserted ahead of "need". We only need to if the probing
> actually succeeds.
>
> > 2. Even if the expression has the same name as GPR, only
> > my_getSmallExpression is possible to set exp to O_register, but
> > my_getExpression won't have, so the probing_insn_operands is used to
> > distinguish between them?
>
> Yes, albeit I find this distinction between the two functions suspicious
> (and as said in a post-commit-message remark I'm also having trouble
> spotting a pattern of when which of the two functions is [to be] used).
> But I didn't want to affect existing behavior too much; iirc there was
> at least one testcase which would break otherwise. As said elsewhere -
> as a first step towards further improvements it would need settling on
> what the intended behavior in various cases actually ought to be.
>
> As to the role of probing_insn_operands: Its two possible non-zero
> values distinguish these two cases; zero vs non-zero distinguish whether
> we deal with insn operands vs directive (or alike) ones.
>
> Jan