Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string
Hi Jim: > I think it is reasonable to start a discussion in riscv-isa-manual, to > try to get an official answer for what is valid and how to interpret > it, instead of just making up our own rules. Agree, issue[1] created on riscv-isa-manual. [1] https://github.com/riscv/riscv-isa-manual/issues/533
Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string
On Tue, Jun 30, 2020 at 8:16 PM Kito Cheng wrote: > I agree the version of G is kind of problematic for GCC implementation, > That reminds me there was a long discussion[1] last year, > The conclusion is version of G is too confusing, it might just don't > accept any version for G. > I thought it could deprecate the version for G in GCC 11 and then drop > that in GCC 12? > For riscv-isa-manual, we could ask them to add a note about the G > don't accept version? > What do you think about this? I think it is reasonable to start a discussion in riscv-isa-manual, to try to get an official answer for what is valid and how to interpret it, instead of just making up our own rules. Jim
Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string
Committed with coding style fixing. On Wed, Jul 1, 2020 at 11:16 AM Kito Cheng wrote: > > Hi Jim: > > > This isn't a criticism of your patch, but I noticed while looking at > > this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd > > are all numbered independently. It doesn't make much sense to specify > > a version with g and assume it is correct for all of imafd. Similarly > > with the implied extensions, e.g. dXpY is expanded to fXpY_dXpY, > > though in this case it is likely that f and d numbers will remain > > compatible. And q too. Still it looks a bit funny to be making that > > assumption and there probably will be other examples where the > > versions of the implied extensions won't match the specified > > extension. Actually I see that f implies Zicsr, and those two have > > different version numbers, we just haven't implemented Zicsr yet. We > > are correctly implementing the rules as specified, the rules just > > don't make sense here. We probably need to file an issue against the > > riscv-isa-manual project for a clarification of how to handle this > > stuff. > > I agree the version of G is kind of problematic for GCC implementation, > That reminds me there was a long discussion[1] last year, > The conclusion is version of G is too confusing, it might just don't > accept any version for G. > I thought it could deprecate the version for G in GCC 11 and then drop > that in GCC 12? > For riscv-isa-manual, we could ask them to add a note about the G > don't accept version? > What do you think about this? > > And the -misa-spec is supported on the binutils side, so I guess it's > time to start to improve > those things on GCC now. > > [1] > https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ > > Thanks :) > > > > > Jim
Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string
Hi Jim: > This isn't a criticism of your patch, but I noticed while looking at > this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd > are all numbered independently. It doesn't make much sense to specify > a version with g and assume it is correct for all of imafd. Similarly > with the implied extensions, e.g. dXpY is expanded to fXpY_dXpY, > though in this case it is likely that f and d numbers will remain > compatible. And q too. Still it looks a bit funny to be making that > assumption and there probably will be other examples where the > versions of the implied extensions won't match the specified > extension. Actually I see that f implies Zicsr, and those two have > different version numbers, we just haven't implemented Zicsr yet. We > are correctly implementing the rules as specified, the rules just > don't make sense here. We probably need to file an issue against the > riscv-isa-manual project for a clarification of how to handle this > stuff. I agree the version of G is kind of problematic for GCC implementation, That reminds me there was a long discussion[1] last year, The conclusion is version of G is too confusing, it might just don't accept any version for G. I thought it could deprecate the version for G in GCC 11 and then drop that in GCC 12? For riscv-isa-manual, we could ask them to add a note about the G don't accept version? What do you think about this? And the -misa-spec is supported on the binutils side, so I guess it's time to start to improve those things on GCC now. [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aZhMG7NIVTk/m/hX2BRWsMEQAJ Thanks :) > > Jim
Re: [PATCH] RISC-V: Preserve arch version info during normalizing arch string
On Mon, Jun 29, 2020 at 7:00 PM Kito Cheng wrote: > - Arch version should preserved if user explicitly specified the version. > e.g. > After normalize, -march=rv32if3d should be -march=rv32i_f3p0d > instead of-march=rv32ifd. This looks good to me. > +explicit_version_p(false) I'd suggest a space before the open paren. This isn't a criticism of your patch, but I noticed while looking at this that we accept gXpY and expand to iXpY_mXpY_ etc. However, imafd are all numbered independently. It doesn't make much sense to specify a version with g and assume it is correct for all of imafd. Similarly with the implied extensions, e.g. dXpY is expanded to fXpY_dXpY, though in this case it is likely that f and d numbers will remain compatible. And q too. Still it looks a bit funny to be making that assumption and there probably will be other examples where the versions of the implied extensions won't match the specified extension. Actually I see that f implies Zicsr, and those two have different version numbers, we just haven't implemented Zicsr yet. We are correctly implementing the rules as specified, the rules just don't make sense here. We probably need to file an issue against the riscv-isa-manual project for a clarification of how to handle this stuff. Jim
