• Address comments.

• Clang formatting.

• Address comments.

• Address comments.

• Revert vector code in favour of auto-vectorisation.

• Add support for vector types.

FRINT only handles f64 so I'm updating the patch to handle the remaining scalar types.

• Change rounding method to match GlobalISel.

Is there a way to detect when new feature attributes are added and raise a warning if this pass hasn't been updated?

In D137954#3936521, @foad wrote:

In D137954#3933743, @Leonc wrote:

The warning is from clang-format. It wants to make 86 changes over hundreds of lines unrelated to this patch.

clang-format-changes.diff64 KBDownload

No, it only wants correct formatting for the lines you actually changed in your patch. If you "install" git clang-format, by making sure llvm-project/clang/tools/clang-format/git-clang-format is on your $PATH, then you can run: git clang-format @^. This is what the Harbormaster build does.

• Changes required by clang-format.

The warning is from clang-format. It wants to make 86 changes over hundreds of lines unrelated to this patch.

• Rebase.

Couldn't reproduce pre-merge warning locally.
All tests have passed successfully.

• Address comments.

• Move test file.

@arsenm how's this? The tests are unified, but it seems a little misleading to have ISel and GlobalISel tests in the same directory.

• Address comments.

In D137954#3925014, @arsenm wrote:

Can you also take care of globalisel here?

• Add FileCheck directives.

• Revert GCN prefixes.

• Add GCN prefix.

Comments on SWDEV-353076 suggested there was a related issue with roundeven but I wasn't able to find any.

Abandoning in favour of updating device-libs.

In D123693#3703089, @arsenm wrote:

We also probably should clean up the the encoding to rely on subtarget features instead of the generation check

• Remove debug code.

• Address comments.

• Address comments.

• Address comments and fix tests.

• Address comments.

• Add v_illegal assembly tests.
• Update instruction definitions.

• Fix ternary args.

• Fix indentation, braces, and file mode.

• Add different versions of V_ILLEGAL for different targets.

• Handling for atomics plus tests.

• Address comments.

• Revert changes to return values.
• Refactor code.
• Address comments.

• Fix existing test failures.

In D123693#3580962, @foad wrote:

In D123693#3580924, @Leonc wrote:

In D123693#3580902, @foad wrote:

The issue is our libraries contain code for all targets. We rely on dead code elimination to remove illegal intrinsics, but that doesn't happen on -O0.

Why can't you put the code for different subtargets in different functions, each with an appropriate "target-cpu"= attribute?

That's what I would do. I think there's some resistance to it though, and it would probably require a lot more work.

Well I am resistant to selecting intrinsics on subtargets that don't support them :)

How far are you planning to go with this approach? Do you expect to extend it to all AMDGPU intrinsics?

In D123693#3580902, @foad wrote:

The issue is our libraries contain code for all targets. We rely on dead code elimination to remove illegal intrinsics, but that doesn't happen on -O0.

Why can't you put the code for different subtargets in different functions, each with an appropriate "target-cpu"= attribute?

In D123693#3580812, @foad wrote:

Where's the rationale? Surely unsupported intrinsics should fail to select, and perhaps be diagnosed even earlier?

Next steps:

• Revert rebase error.

• Updates toward catching and handling all illegal intrinsics.