On 2023/08/15 12:38, Tsukasa OI wrote: > > On 2023/08/14 21:51, Jin Ma wrote: > >> Hi Tsukasa, > >> What a coincidence, I also implemented zfa extension, which also > >> includes fli related instructions :) > > > > Hi, I'm glad to know that someone is working on this extension more > > comprehensively (especially when "someone" is an experienced GCC > > contributor). I prefer your patch set in general and glad to learn from > > your patch set and your response that my approach was not *that* bad as > > I expected. > > > > When a new extension gets available, I will be more confident making a > > patch set for GCC (as I already do in GNU Binutils). > > > >> > >> links: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627294.html > >> > >>> + if (!TARGET_HARD_FLOAT || !TARGET_ZFA) > >>> + return result; > >>> + switch (GET_MODE (x)) > >>> + { > >>> + case HFmode: > >>> + /* Not only 'Zfhmin', either 'Zfh' or 'Zvfh' is required. */ > >>> + if (!TARGET_ZFH && !TARGET_ZVFH) > >> > >> When Zvfh means that zfh is also on, so there may be no need to judge > >> the TARGET_ZVFH here. By the way,the format here seems wrong, maybe 'tab' > >> is needed for alignment? > > > > For indentation, I believe this is okay considering 3 indent (soft tab) > > from the top (meaning 6 spaces). > > > > For specification requirements, I think I'm correct. > > > > The spec says that 'Zvfh' depends on 'Zve32f' and 'Zfhmin'. 'Zfhmin' is > > a conversion-only 'Zfh' subset ('Zve32f' doesn't require any > > FP16-related extensions). > > > > Note that "fli.h" requires 'Zfa' and ('Zfh' and/or 'Zvfh'). > > > > So, 'Zfh' alone will not be sufficient to check requirements to the > > "fli.h" instruction. So, checking TARGET_ZFH || TARGET_ZVFH (for > > existence of the "fli.h") should be correct and I think your patch needs > > to be changed "in the long term". > > > > "In the long term" means that, current GNU Binutils has a bug which > > "fli.h" requires 'Zfa' and 'Zfh' ('Zfa' and 'Zvfh' does not work). > > My initial 'Zfa' proposal (improved by Christoph Müllner and upstreamed > > into master) intentionally ignored this case because I assumed that > > approval/ratification of 'Zvfh' will take some time and we have a time > > to fix before a release of Binutils following approval of both 'Zfa' and > > 'Zvfh' (it turned out to be wrong). > > > > cf. <https://sourceware.org/pipermail/binutils/2023-August/129006.html> > > > > So, "fixing" this part (on your patch) alone will not make the program > > work (on the simulator) because current buggy GNU Binutils won't accept > > it. I'm working on it on the GNU Binutils side. > > Okay, the bug is fixed on GNU Binutils (master) and waiting approval > from the release maintainer (for binutils-2_41-branch). > > Thanks, > Tsukasa >
Yes, you are right. I did not notice that zfh and zvfh are relatively independent.
