[llvm] [ARM] Recognize abi tag module flags (PR #161306)

[via llvm-commits]

paperchalice wrote:

> I'm still a bit unsure about what to do in the LTO case.
>
> What I'm concerned about is something like:
> clang -flto (non-default options one or more of these flags) src1.c
> clang -flto (non-default options one or more of these flags) src2.c
> clang -flto src1.o src2.o -o output.exe (module flags get defaults)

> We've been asked to fix problems like this with architecture flags as this does occur in projects that separate their compile and > link flags.

Test locally with llvm-lto/llvm-link, but I think it should also be true for clang...
It will output something like
```sh
linking module flags 'arm-eabi-fp-number-model': IDs have conflicting values ('i32 2' from src2.bc with 'i32 1' from ld-temp.o)
```
The final tag value comes from the first input moudle.

> In the linked PR #161106 you mention that UnsafeFPMath and related flags were disappearing. I wasn't sure what that referred to. If the per function attributes are disappearing and the module flags are all we have then there's not much more we can do, perhaps making sure we release note it so that users can make sure they add the flags to their link line.

Sorry for the unclear explaination, I mean fast-math related function attributes like "unsafe-fp-math", and the `--enable-unsafe-fp-math/UnsafeFPMath` option in `llvm/lib/CodeGen`.

> Alternatively it may be worth looking at all the functions, and if they are all consistent, but different from the module flags then use the function flags.

This is the implementation before https://github.com/llvm/llvm-project/pull/151275, but was is already broken during iteration...

We can remove these function attributes support directly because they are undocumented, but should we document these new module flags?

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