Implementation and testing of ACLE 2.0 macros, for details see the above document:
ACLE 2.0
Details
Diff Detail
Event Timeline
I'm surprised you decided to rearrange the output of the macros. It makes reviewing a lot harder. Is there some special reason to have that in any specific order?
lib/Basic/Targets.cpp | ||
---|---|---|
4624 | Is it truly impossible for CPUAttr to be empty? Or just coincidental given our tests? |
lib/Basic/Targets.cpp | ||
---|---|---|
4757 | According to the ACLE document, current AArch32 NEON implementations do not support double-precision floating-point even when it is present in VFP. |
lib/Basic/Targets.cpp | ||
---|---|---|
4685–4686 | Good point. As far as I know there is hardware support for having _fp16 type values as function arguments but not as return values (yet). If so, should _ARM_FP16_ARGS macro be defined or not? (ACLE 2.0: "_ARM_FP16_ARGS is defined to 1 if __fp16 can be used as an argument and result.") |
lib/Basic/Targets.cpp | ||
---|---|---|
4685–4686 | Support for __fp16 args/returns should be independent of hardware support (at least in clang/llvm), as we can always lower to library function calls. For AArch32: There is currently no support for __fp16 arguments or returns, but D12148 adds both of these, and sets the predefine. For AArch64: There has been support for __fp16 args and returns for about a year, but we only recently turned the predefine on (D12240/rL245833). |
lib/Basic/Targets.cpp | ||
---|---|---|
4685–4686 | Good. I will update this patch accordingly. |
_ARM_FP16_FORMAT_IEEE and _ARM_FP16_ARGS should be defined unconditionally. When hardware does not support it library calls are emitted.
Hi Alexandros,
Sorry, I was on holidays. Apart from my comment, everything else looks good.
cheers,
--renato
lib/Basic/Targets.cpp | ||
---|---|---|
4788 | Isn't there a combination where you'll emit this macro twice? |
Also, the target parser code has changed, please make sure it still works with the new version.
lib/Basic/Targets.cpp | ||
---|---|---|
4788 | This could be addressed as: bool hasDSP = false; if (is5EOrAbove && is32Bit && (CPUProfile != "M" || CPUAttr == "7EM")) { Builder.defineMacro("__ARM_FEATURE_DSP", "1"); hasDSP = true; } bool hasSAT = false; if ((ArchVersion == 6 && CPUProfile != "M") || ArchVersion > 6 ) { Builder.defineMacro("__ARM_FEATURE_SAT", "1"); hasSAT = true; } if (hasDSP || hasSAT) Builder.defineMacro("__ARM_FEATURE_QBIT", "1"); |
lib/Basic/Targets.cpp | ||
---|---|---|
4788 | Yup, that looks good. |
Is it truly impossible for CPUAttr to be empty? Or just coincidental given our tests?