Some of the the permissible ARM -mfpu (floating-point hardware) options, which are already supported in GCC, are currently not present in llvm/clang. This patch adds, namely, the options 'neon-fp16', 'vfpv3-fp16', 'vfpv3-d16-fp16', 'vfpv3xd' and 'vfpv3xd-fp16. These options are related to half-precision floating-point and single precision.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hi Javed,
This patch LGTM with two little comments but you should probably wait for Renato or John to do the final review before you commit.
Thanks,
Ranjeet
include/llvm/Support/TargetParser.h | ||
---|---|---|
59 ↗ | (On Diff #28214) | add space at start of comment "// FPU Version" |
lib/Support/TargetParser.cpp | ||
56 ↗ | (On Diff #28214) | Remove the space between the last quote and the comma. |
include/llvm/Support/TargetParser.h | ||
---|---|---|
42 ↗ | (On Diff #28214) | Do we even support this? You're not adding this to the parser nor tests. I think this should go until we have a reason to put it in. |
Hi Renato:
Regarding your comment on VFPV3XD, I have added tests to in my patch (http://reviews.llvm.org/differential/diff/28232/) and tests for all other cases as well. These options are supported by gcc and vfpv3xd- is a valid option for r5.
Hi Javed,
You somehow overrode the previous patch. You should commit tests with the patch, not as separate.
Even if you keep them as separate patches in git (I usually do), when sending to Phab you need to diff against master (git diff -U999 master > patch), so that Phab can track it correctly.
Also, about vfpv3xd, what I mean is that we don't differentiate vfpv3 from vfpv3xd, so there's no point in having a new enum value for it. If it's just an alias, then you can add it to the table, but map it to FK_VFPV3_D16 and FK_VFPV3_D16_FP16.
Unless it really makes a difference if you want to get the *same* string back later for (say) the assembler or linker. Since we have no use at all of that tag in the whole of LLVM+Clang codebase, I don't think adding it here makes any sense without a strong reason, which can (and should) be tested.
cheers,
--renato
One more thing... In addition to testing the string matching of VFPV3XD, we also need to add them to every place in LLVM that uses that enum as base for a switch or parameter, and make sure that wherever it *is* different, we make it work differently. Not to mention testing all of it, which is quite a lot of work.
So, unless we have a strong reason to differentiate, there's no point in doing it. At least, not now.
Hi Renato:
"about vfpv3xd, what I mean is that we don't differentiate vfpv3 from vfpv3xd, so there's no point in having a new enum value for it. If it's just an alias, then you can add it to the table, but map it to FK_VFPV3_D16 and FK_VFPV3_D16_FP16"
vfpv3xd is different from FK_VFPV3_D16 since for vfpv3xd the FPURestriction value is FR_SP_D16, while for VFPV3_D16 the FPURestriction value is FR_D16.
"You somehow overrode the previous patch. You should commit tests with the patch, not as separate"
Yes I assumed phabricator would manage the clang and llvm diffs properly when loaded separatly. I can create separate reviews for clang and lvvm (but probably too late this time) but instead i will just append the two diffs together into one diff and see it is handled properly.
". In addition to testing the string matching of VFPV3XD, we also need to add them to every place in LLVM that uses that enum as base for a switch or paramet"
Yes you are right. I need to add to ELFStreamer and AsmPrinter. I will do so in next patch and see if that's doable and satisfactory.
Thanks for your comments.
Oh, I see. Makes sense.
Yes you are right. I need to add to ELFStreamer and AsmPrinter. I will do so in next patch and see if that's doable and satisfactory.
Thanks for your comments.
Ok, that should be fine in a separate patch.
Just resubmit the whole thing here again, with the comments from me and Ranjeet, and it should be fine.
cheers,
--renato
Hi Renato/Ranjeet:
I have updated the patch based on your comments. Apart from minor formatting changes, specifically, I added changes to ELFStreamer and ARMAsmPrinter to ensure that the new fpu options are reflected in the objectfille and printed assembly. I have added tests for both cases.
Also, since my earlier clang and llvm patches were over-writting each other, I have submitted a separate patch for the clang side changes (patch is identical to earlier one).
Thanks and Best Regards,
Javed