[llvm-branch-commits] [clang] release/22.x: [Hexagon] Define __HVX_IEEE_FP__ ; Use __HVX_IEEE_FP__ to guard protos (PR #185014)

[Brian Cain via llvm-branch-commits]

androm3da wrote:

> @androm3da my main concern with this change is that the header file changes could introduce an ABI break which we do not want to do. To me it looks like the header file changes just define additional macros on some versions of the architecture that previously did not. Is that correct?

That is correct.  Further: the macros are defining architecture-specific intrinsics.  And in this case, the header file changes are making 
 
> And can you confirm that this is not introducing an ABI break?

I ... don't think so.  Is there even an ABI for architecture-specific intrinsics?

But let me try and speculate on how things could go wrong here.  A program being incorrectly built with the 22.1.0 clang via `--target hexagon-linux-musl -mv73 -mhvx` but leveraging IEEE FP opcodes via intrinsics would previously get compiled successfully.  That same program again built with 22.1.3 clang via `--target hexagon-linux-musl -mv73 -mhvx` (incorrectly omitting `-mhvx-ieee-fp`) would get an error.

I guess this is the kind of breakage you might be concerned about, but I see it not as ABI conformance/non-conformance but instead the compiler correctly diagnosing where it previously did not.  Do we have a precedent for/against making the compiler stricter in a patch release?

https://github.com/llvm/llvm-project/pull/185014