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 | ||
|---|---|---|
| 4621 | Is it truly impossible for CPUAttr to be empty? Or just coincidental given our tests? | |
| lib/Basic/Targets.cpp | ||
|---|---|---|
| 4775 | 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 | ||
|---|---|---|
| 4687–4688 | 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 | ||
|---|---|---|
| 4687–4688 | 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 | ||
|---|---|---|
| 4687–4688 | 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 | ||
|---|---|---|
| 4794 | 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 | ||
|---|---|---|
| 4794 | 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 | ||
|---|---|---|
| 4794 | Yup, that looks good. | |
Is it truly impossible for CPUAttr to be empty? Or just coincidental given our tests?