If this cannot be reproduced with the OSS LLVM, I am not sure you should adjust such a test.

Abandoned because lack of reaction for such an unimportant issue.

ping

removed clang/test/CodeGen/lit.local.cfg.py

addressed review comment to hardwire non-MS target platforms

Hi @MaskRay. Yes, so we're seeing a warning specific to our Armcompiler toolchain, so I'm guessing that isn't relevant to OSS LLVM:
armclang: warning: '--target=x86_64-unknown-linux' is not supported.

After committing this patch, clang/test/CodeGen/volatile.c failed on Arm/AArch64 buildbot hosts. The reason for this is that %itanium_abi_triple, a run line Lit target triple substitution at the top of the file, is filled in with the host arch triple. For example: aarch64-unknown-linux-gnu. I've amended the tests to take into account the changes to code generation in this patch.

Reopening as this commit made clang/test/CodeGen/volatile.c fail on Arm/AArch64 buildbot hosts.

slight change in commit message

I'm not sure what the procedure is to get patches into LLVM 11, but I think there's still time. Could you try to get this in there as well @c-rhodes ?

Thanks, this one crept in during mass-renaming.

addressed review comment

Commandeering as I've made some changes to the patch.

@ostannard: pinging on behalf of @dnsampaio. The changes still apply cleanly.

Looks harmless :o) Thanks, LGTM.

addressing review comments

In D85101#2190026, @dmgreen wrote:

Quick question - what is the expected behaviour? Do we just never expect to see an bf16 add, and if we do it's a fatal error? Or is some form of automatic promotion expected to happen?

addressed review comment

LGTM

LGTM. Thanks!

LGTM

In D81451#2092997, @pratlucas wrote:

Hi @stuij,

The changes to the backend only handle the half (f16) type itself, not vectors that have it as their base type.

From what I've checked on the AAPCS, the rules for handling those types are a bit different and they would require their own handling in the backend's calling convention lowering.
I haven't looked into the backend's handling of those types in detail, but I believe a similar approach to the one taken for f16 would be possible for the vector types as well.

We only remove clang-side lowering for non-vector bfloat types.

LGTM. Thanks :)

I would have expected changes for neon as well.

adjust arm bfloat mangle tests for these changes

LGTM. Thanks!

LGTM. Thanks!

Ah, awesome. Thanks :)

Yup, LLVM now builds and check-all's. Thanks for fixing!

ah sorry, I guess that might have been the wrong link. My copy pasting skills are flaky.

Seems like this is breaking on buildbot (and also my local checkout): http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/16759

addressed remaining nits

Resolved merge conflicts with head. Fixed minor oversight.

In D80716#2073251, @LukeGeeson wrote:

Besides from rebasing to get @pratlucas changes upstream.

@stuij please could you confirm if you are happy with this, so I can merge

For the backend tests, I suggest using -asm-verbose=0 with llc to only print instructions and get rid of // kill: .. and friends. Use update_cc_test_checks.py again to regenerate the testing.

Addressed review comments. Notably what to do in combination with -mfloat-abi=soft.

In D76077#2066520, @SjoerdMeijer wrote:

At the moment when going through the GCC compatibility driver (standard interface), we get __bf16 is not supported on this target.

If this is the current behaviour, and consistent with GCC, that sounds reasonable.

In D76077#2066323, @SjoerdMeijer wrote:

Can you summarise where we are? I.e.,

• float-abi=soft doesn't work. But what is the problem? Are we not simply passing i16s, is that not what we are supposed to do?

We need testing for the backend code.