[PATCH] D76612: [Matrix] Add draft specification for matrix support in Clang.

SjoerdMeijer added inline comments. Comment at: clang/docs/MatrixTypes.rst:27 +internal layout, overall size and alignment are implementation-defined. +A *matrix element type* must be a real type (as in C99 6.2.5p17) excluding +enumeration types or an implementation-defined half-

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks, LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76077/new/ https://reviews.llvm.org/D76077 ___

cfe-commits@lists.llvm.org

SjoerdMeijer added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 +

cfe-commits@lists.llvm.org

SjoerdMeijer added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 +

cfe-commits@lists.llvm.org

SjoerdMeijer added inline comments. Comment at: llvm/test/CodeGen/AArch64/aarch64-bf16-ldst-intrinsics.ll:264 +; Function Attrs: argmemonly nounwind readonly +declare { <8 x bfloat>, <8 x bfloat> } @llvm.aarch64.neon.ld2lane.v8bf16.p0i8(<8 x bfloat>, <8 x bfloat>, i64, i8*) #3 +

[PATCH] D75169: [ARM] Supporting lowering of half-precision FP arguments and returns in AArch32's backend

SjoerdMeijer added inline comments. Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:524 + CallConv)) +return; EVT ValueVT = Val.getValueType(); efriedma wrote: > pratlucas wrote: > > efriedma wrote: >

[PATCH] D50229: [ARM][AArch64] Add feature +fp16fml

SjoerdMeijer marked an inline comment as done. SjoerdMeijer added inline comments. Comment at: test/Driver/aarch64-cpus.c:518 +// RUN: %clang -target aarch64 -march=armv8.4-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV84A-NO-FP16FML %s +// GENERICV84A-NO-FP16FML-NOT: "-ta

[PATCH] D83079: [clang] Default target features implied by `-march` on AArch64.

SjoerdMeijer added a comment. I haven't looked into details of these arch extensions yet, will do that tomorrow, but I don't think there's any disagreement, i.e., these options and their behaviour are synchronised with the GCC community. Thus, it's better if you remove this wording from both d

[PATCH] D83079: [clang][aarch64] Generate preprocessor macros for -march=armv8.6a+sve.

SjoerdMeijer added inline comments. Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:118 + + if (!llvm::AArch64::getArchFeatures(ArchKind, Features)) +return false; Would it be more consistent to move this Comment at: clang/lib

[PATCH] D77735: [SveEmitter] Implement builtins for gathers/scatters

SjoerdMeijer accepted this revision. SjoerdMeijer added a reviewer: efriedma. SjoerdMeijer added a comment. This revision is now accepted and ready to land. This is a big patch, but looks reasonable to me. Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7451 + } + llvm_unreachabl

[PATCH] D78401: [SveEmitter] IsInsertOp1SVALL and builtins for svqdec[bhwd] and svqinc[bhwd]

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Looks reasonable Comment at: clang/include/clang/Basic/arm_sve.td:530 +class sat_type { string U = u; string T = t; } +def SIGNED_BYTE : sat_type<"", "c"

[PATCH] D77594: [SveEmitter] Add support for _n form builtins

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Looks reasonable to me Comment at: clang/utils/TableGen/SveEmitter.cpp:212 + bool hasSplat() const { +return Proto.find_first_of("ajfrKLR") != std::string::n

[PATCH] D78511: [Driver][doc] Document option -mtune as a no-op. NFC.

SjoerdMeijer created this revision. SjoerdMeijer added a reviewer: dblaikie. This is a doc change documenting that option -mtune does not perform any CPU type specific tuning but exists for compatability reasons with GCC. https://reviews.llvm.org/D78511 Files: clang/docs/ClangCommandLineRefe

[PATCH] D78511: [Driver][doc] Document option -mtune as a no-op. NFC.

SjoerdMeijer updated this revision to Diff 258823. SjoerdMeijer added a comment. Cheers, that's probably what I wanted to say. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78511/new/ https://reviews.llvm.org/D78511 Files: clang/docs/ClangCommandLineReference.rst clang/include/clan

[PATCH] D78511: [Driver][doc] Document option -mtune as a no-op. NFC.

SjoerdMeijer added a comment. Thank you both for reviewing! And I will wait a day. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78511/new/ https://reviews.llvm.org/D78511 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://list

[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

SjoerdMeijer created this revision. SjoerdMeijer added reviewers: psmith, ostannard, kristof.beyls, chill. Herald added subscribers: danielkiss, arphaman. Following the discussion about -mtune on the cfe dev list, I thought it would be good to make a start with documenting common command line arg

[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

SjoerdMeijer added a comment. Hi Peter, Thanks for reviewing again! I thought these examples to be relevant here, because it shows usage and examples of this tool (i.e. open-source clang/llvm). Additional benefits is that source and documentation is in one place, and it allows others, non-Arm p

[PATCH] D78511: [Driver][doc] Document option -mtune as a no-op. NFC.

This revision was automatically updated to reflect the committed changes. Closed by commit rG35cf2f42dda4: [Driver][docs] Document option -mtune as a no-op. (authored by SjoerdMeijer). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://review

[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

SjoerdMeijer abandoned this revision. SjoerdMeijer added a comment. Fair enough, perhaps the audience is too small here on llvm.org for this and this is too niche. In A-profile we have the same problem, so could the exercise for an A-core here, but can't spend time on that now, so will abandon t

[PATCH] D78565: [clang][doc] Clang ARM CPU command line argument reference

SjoerdMeijer added a comment. To be completely open about this, I had an offline chat with @psmith and @kristof.beyls about this. The reasoning is that this is probably related to my relatively poor choice of the 2 first cores that I describe here. They are microcontrollers, and Clang/LLVM do

[PATCH] D78190: Add Bfloat IR type

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. This direction of an IR type was taken after a discussion on the list. All previous comments have been addressed, and the changes here all look very reasonable to me. So, LGTM, but

[PATCH] D78995: [SveEmitter] NFCI: Describe splat operands like any other modifier

SjoerdMeijer added inline comments. Comment at: clang/utils/TableGen/SveEmitter.cpp:68 TypeSpec TS; + bool IsSplat; bool Float, Signed, Immediate, Void, Constant, Pointer; I was wondering if IsSplat belongs here or somewhere else. It doesn't sound like a

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64.td:849 + HasV8_1aOps, + HasV8_3aOps]>; + `HasV8_3aOps` implies `HasV8_2aOps`, which implies `HasV8_1a

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. In D78129#2022307 , @joelkevinjones wrote: > In email Wei asked for help about he following error message: > > error message from tblgen > Included from > /home/wei/project/tx3/llvm-project/llvm/lib/Target/AArch64/AArch6

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. Since debugging on phabricator is a bit difficult, I took the patch and had a little play. Now I actually remember seeing this before. I think the way this works is that when you describe new instructions (PA in this case) that other models don't have, they start c

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. Agreed about the UnsupportedFeatures list. But I just wanted to unblock this work, create a first version that compiles, so you can pick it up and clean things further up. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. Let's separate out HasPA from SVEFeatures now while we are at it, probably it's more work to do this as a follow up, and after that this looks good to me. Bonus points for adding some llvm-mca tests, see the `llvm-project/llvm/test/tools/llvm-mca/` directory for so

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. In D78129#2023772 , @joelkevinjones wrote: > I don't think it makes sense to combine two unrelated things SVE and PA > support into a combined thing. Since we already have UnsupportedFeatures in > every sub-target .td file,

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. This looks good now, but sorry, one more request: I've just noticed a Clang driver test is missing. Can you add a test for this to `clang/test/Driver/aarch64-cpus.c`? And related to this, the relevant tests to `llvm/unittests/Support/TargetParserTest.cpp`? CHANGE

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks, LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78129/new/ https://reviews.llvm.org/D78129 ___

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. Forgot to ask/add: can you commit this, do you have commit rights? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78129/new/ https://reviews.llvm.org/D78129 ___ cfe-commits

[PATCH] D79708: [clang][BFloat] add NEON emitter for bfloat

SjoerdMeijer added inline comments. Comment at: clang/include/clang/Basic/arm_bf16.td:1 +//===--- arm_fp16.td - ARM FP16 compiler interface ===// +// typo: fp16 - > bf16? Here, and a few more places, or is it intentional? If so, I guess t

[PATCH] D78190: Add Bfloat IR type

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. Nothing much has changed here: there was already broad consensus on this change and direction, and the last few weeks we have only seen a few rounds of minor comments and nits, so still LGTM. Please wait a day with committing to

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer added inline comments. Comment at: clang/docs/LanguageExtensions.rst:518 +Clang supports three half-precision (16-bit) floating point types: ``__fp16``, +``_Float16`` and ``__bf16``. These types are supported in all language modes. Not my field of

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer added inline comments. Comment at: clang/docs/LanguageExtensions.rst:518 +Clang supports three half-precision (16-bit) floating point types: ``__fp16``, +``_Float16`` and ``__bf16``. These types are supported in all language modes. stuij wrote: >

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer added inline comments. Comment at: clang/docs/LanguageExtensions.rst:518 +Clang supports three half-precision (16-bit) floating point types: ``__fp16``, +``_Float16`` and ``__bf16``. These types are supported in all language modes. stuij wrote: >

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8111 "pointer cannot be cast to type %0">; +def err_cast_to_bfloat : Error<"cannot type-cast to __bf16">; +def err_cast_from_bfloat : Error<"cannot type-cast from __bf16">; ---

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

SjoerdMeijer added a comment. There are Sema and CodeGen tests, but was wondering if there would be some value in having an AST test too? There are some other types that do have AST tests. Comment at: clang/lib/AST/ASTContext.cpp:2052 + Width = Target->getBFloat16Width()

[PATCH] D78129: Add Marvell ThunderX3T110 support

SjoerdMeijer added a comment. Best to ask the release manager. Today Tom Stellard posted a message to the llvm dev list with subject: [llvm-dev] LLVM 10.0.1-rc1 release update So best to reply to this(*) asap with your query if it's possible to get this onto the branch. (*) http://lists.llv

[PATCH] D40888: [ARM] ACLE parallel arithmetic and DSP style multiplications

SjoerdMeijer created this revision. Herald added subscribers: kristof.beyls, javed.absar, aemerson. This is a follow up of r302131, in which we forgot to add SemaChecking tests. Adding these tests revealed two problems which have been fixed: - added missing intrinsic __qdbl, - properly ran

[PATCH] D40888: [ARM] ACLE parallel arithmetic and DSP style multiplications

SjoerdMeijer added inline comments. Comment at: include/clang/Basic/BuiltinsARM.def:39 BUILTIN(__builtin_arm_qsub, "iii", "nc") +BUILTIN(__builtin_arm_qdbl, "ii", "nc") BUILTIN(__builtin_arm_ssat, "iiUi", "nc") samparker wrote: > Do we now need a codegen tests

[PATCH] D40888: [ARM] ACLE parallel arithmetic and DSP style multiplications

This revision was automatically updated to reflect the committed changes. Closed by commit rC320019: [ARM] ACLE parallel arithmetic and DSP style multiplications (authored by SjoerdMeijer). Repository: rC Clang https://reviews.llvm.org/D40888 Files: include/clang/Basic/BuiltinsARM.def lib

[PATCH] D40888: [ARM] ACLE parallel arithmetic and DSP style multiplications

This revision was automatically updated to reflect the committed changes. Closed by commit rL320019: [ARM] ACLE parallel arithmetic and DSP style multiplications (authored by SjoerdMeijer). Changed prior to commit: https://reviews.llvm.org/D40888?vs=125705&id=125909#toc Repository: rL LLVM

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. In D113779#3496589 , @fhahn wrote: > In D113779#3207936 , @SjoerdMeijer > wrote: > >>> If anybody has contacts to GCC that would be very helpful. Unfortunately I >>> don't think I w

[PATCH] D66290: [clang] Pragma vectorize_width() implies vectorize(enable)

SjoerdMeijer added a comment. Thanks, and sorry for the delay. Back in the office now, and I am addressing this: > I think it would be slightly better to split off the change to disable > vectorization via llvm.loop.vectorize.enable=false instead of width=1. Yep, I agree CHANGES SINCE LAST A

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

SjoerdMeijer created this revision. SjoerdMeijer added reviewers: fhahn, Meinersbur, hsaito, Ayal. This changes the behaviour of vectorize(disable). I.e., disabling vectorization now means disabling vectorization, and not setting the vectorization width to 1. This is a follow up of the discussion

[PATCH] D66290: [clang] Pragma vectorize_width() implies vectorize(enable)

SjoerdMeijer added a comment. > I think it would be slightly better to split off the change to disable > vectorization via llvm.loop.vectorize.enable=false instead of width=1. This is now D66796 . I will now start stripping it out from this patch. CHANGES SINC

[PATCH] D66290: [clang] Pragma vectorize_width() implies vectorize(enable)

SjoerdMeijer updated this revision to Diff 217383. SjoerdMeijer edited the summary of this revision. SjoerdMeijer added a parent revision: D66796: [clang] Loop pragma vectorize(disable). SjoerdMeijer added a comment. Stripped out the functional change related to vectorize(disable). CHANGES SINC

[PATCH] D66199: [docs] loop pragmas

SjoerdMeijer added a comment. Many thanks for your clarification! > What we were discussing was that these settings would remove 0) from the > candidate list as well. Yep, that's crystal clear now. And my expectation would indeed be that this would be the case. CHANGES SINCE LAST ACTION h

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

SjoerdMeijer added a comment. > Therefore, vectorize(disable) would also disable interleaving? I don't have strong opinions on this. I think there's something to say for both options that we have (i.e. `vectorize(disable)` disables interleaving or enables it). But I think it was @fhahn who ment

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

SjoerdMeijer added a comment. friendly ping. Shall we get this in, so that I can commit this and D66290 ? Then, we can perhaps continue the interleave discussion separately? I will then return to the doc patch first in D66199

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

SjoerdMeijer added a comment. Hi Hideki, I think you're comments are spot on: > It all depends on to whom we are providing these pragmas. Pragma's are user-facing "options" to override or force compiler decision making. I don't think there's another way to look at it, but please correct me i

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

SjoerdMeijer added a comment. And thanks Florian for getting this discussion going again! Will definitely make this clear(er) in this description and commit message once we agree on it. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66796/new/ https://reviews.llvm.org/D66796

[PATCH] D33719: Add _Float16 as a C/C++ source language type

SjoerdMeijer added a comment. Ping https://reviews.llvm.org/D33719 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33719: Add _Float16 as a C/C++ source language type

SjoerdMeijer added a comment. Ping https://reviews.llvm.org/D33719 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36731: [ARM][AArch64] Cortex-A75 and Cortex-A55 support

SjoerdMeijer added a comment. "They also implement the RCpc AArch64 extension from ARMv8.3-A." Perhaps you need to explain why a v8.2 core implements a v8.3 extension? Comment at: lib/Driver/ToolChains/Arch/ARM.cpp:92 + std::vector &Features

[PATCH] D36731: [ARM][AArch64] Cortex-A75 and Cortex-A55 support

SjoerdMeijer added a comment. Ah, my message crossed with Renato's; I only noticed it after submitting mine (looks like we agree though:-)) https://reviews.llvm.org/D36731 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.or

[PATCH] D36731: [ARM][AArch64] Cortex-A75 and Cortex-A55 tests

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Looks good to me too. Two nits (no new review required): one is inlined, and the other one in the summary: ARMv8.2-A => Armv8.2-A :-/ Comment at: test/Driver/

[PATCH] D36666: [ObjC] Use consistent comment style in inline asm

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Looks reasonable to me. Repository: rL LLVM https://reviews.llvm.org/D3 ___ cfe-commits mailing list cfe-commits@lists.llvm.or

[PATCH] D37106: [Driver][AArch64] Tests for rdm feature.

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks for fixing this. https://reviews.llvm.org/D37106 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org

[PATCH] D57054: [MachineOutliner][ARM][RFC] Add Machine Outliner support for ARM

SjoerdMeijer added a subscriber: samparker. SjoerdMeijer added a comment. Just a quick message, linking in @samparker, and I guess moving Low Overhead Loops to run before ConstantIslands could be problematic, but we can/should have a proper look tomorrow. Repository: rG LLVM Github Monorepo

[PATCH] D91994: [AArch64] Cortex-R82: remove crypto

This revision was automatically updated to reflect the committed changes. Closed by commit rG99ad078b91ed: [AArch64] Cortex-R82: remove crypto (authored by SjoerdMeijer). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

SjoerdMeijer added inline comments. Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3080 } Opts.setFPExceptionMode(FPEB); jansvoboda11 wrote: > The parsing of `OPT_ftrapping_math` and `OPT_fno_trapping_math` is > immediately overwritten here. Yeah,

[PATCH] D93395: [clang][cli] Remove -f[no-]trapping-math from -cc1 command line

SjoerdMeijer added inline comments. Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3080 } Opts.setFPExceptionMode(FPEB); jansvoboda11 wrote: > SjoerdMeijer wrote: > > jansvoboda11 wrote: > > > The parsing of `OPT_ftrapping_math` and `OPT_fno_trappi

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

SjoerdMeijer added a comment. I am very sorry that I am late to this... but I do have some concerns. The concern that I have is that we extend vecorize_width with a scalable/fixed boolean, but there are more vectorisation pragma that set vectorisation options which imply enabling vectorisation:

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

SjoerdMeijer added a comment. In D89031#2391160 , @david-arm wrote: > Hi @SjoerdMeijer I think that given we now support scalable vectors we > thought it made sense to be able to specify whether the user wants 'fixed' or > 'scalable' vectorisation along

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

SjoerdMeijer added a comment. > This approach should be fully complementary to `vectorize_with` so that it > would be possible to have: > > // Use scalable vectors, but leave it to the cost-model to choose the most > efficient N in . > // If the pragma is not specified, it defaults to vector

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

SjoerdMeijer added a comment. Because I was not understanding, we have discussed this further offline. I think the conclusion was: pragma `vectorize_width` controls the vectorisation vector `VF` in ``. where `vscale` is not just a separate thing but it defines a VectorType. That's why it would

[PATCH] D88660: [AArch64] Add CPU Cortex-R82

This revision was automatically updated to reflect the committed changes. Closed by commit rG8825fec37e73: [AArch64] Add CPU Cortex-R82 (authored by SjoerdMeijer). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed prior to commit: https://reviews.llvm.org/D88660?vs=

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

SjoerdMeijer added a comment. Thanks @david-arm for posting this proposal to the cfe list. My confusion has been cleared up. The (new) proposal is to have: 1. vectorize_width(X) where X is an integer. 2. vectorize_width(X, fixed|scalable) 3. vectorize_width(fixed|scalable) And with that 3rd opti

[PATCH] D89972: Add pipeline model for HiSilicon's TSV110

SjoerdMeijer added inline comments. Comment at: clang/test/Driver/aarch64-cpus.c:298 +// RUN: %clang -target aarch64 -mcpu=tsv110 -### -c %s 2>&1 | FileCheck -check-prefix=TSV110 %s +// RUN: %clang -target aarch64 -mlittle-endian -mcpu=tsv110 -### -c %s 2>&1 | FileCheck -chec

[PATCH] D89972: Add pipeline model for HiSilicon's TSV110

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. I haven't checked the instruction descriptions in detail, but the overall structure looks good to me. Perhaps wait a day with committing in case @bryanpkc has more comments. CHAN

[PATCH] D94779: [Clang] Ensure vector predication pragma is ignored only when vectorization width is 1.

SjoerdMeijer added a comment. In D94779#2515157 , @dmgreen wrote: > Thanks. @fhahn @SjoerdMeijer what do we think about the edge case where the > width==1? As far as I understand (with this patch): > > #pragma clang loop vectorize_predicate(disable) vec

[PATCH] D93585: [AArch64][Clang][Linux] Enable out-of-line atomics by default.

SjoerdMeijer added inline comments. Comment at: clang/lib/Driver/ToolChains/Clang.cpp:6448 + CmdArgs.push_back("-target-feature"); + CmdArgs.push_back("+outline-atomics"); +} This needs a Clang driver tests. Repository: rG LLVM Github Monorepo

[PATCH] D93585: [AArch64][Clang][Linux] Enable out-of-line atomics by default.

SjoerdMeijer added a comment. In D93585#2526774 , @ilinpv wrote: > Clang driver tests for outline atomics were added. Thanks! Is there a way we can test `-rtlib=libgcc`? Comment at: clang/lib/Driver/ToolChains/Linux.cpp:855 +const

[PATCH] D93585: [AArch64][Clang][Linux] Enable out-of-line atomics by default.

SjoerdMeijer added a comment. Sorry one last question: how about `-mno-outline-atomics` in combination with this? Think we need to add a test for that too? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93585/new/ https://reviews.llvm.org/D93585 _

[PATCH] D93585: [AArch64][Clang][Linux] Enable out-of-line atomics by default.

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks, LGTM too. One nit inlined that can be addressed before committing. Comment at: clang/test/Driver/aarch64-features.c:47 +// CHECK-OUTLINE-ATOMICS-ON: "-ta

[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks, looks reasonable to me. Comment at: llvm/unittests/Support/TargetParserTest.cpp:495 ARMBuildAttrs::CPUArch::v8_A)); + EXPECT_T

[PATCH] D109517: [Clang][ARM][AArch64] Add support for Armv9-A, Armv9.1-A and Armv9.2-A

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. LGTM Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:419 + + // Enable SVE2 by default on Armv9-A + // It can still be disabled if +nosve2 is present -

[PATCH] D96866: [AArch64] Add some missing Neoverse features

This revision was automatically updated to reflect the committed changes. Closed by commit rG260f90bb3d1a: [AArch64] Add some missing Neoverse features (authored by SjoerdMeijer). Herald added a project: clang. Herald added a subscriber: cfe-commits. Changed prior to commit: https://reviews.llv

[PATCH] D101696: [Matrix] Implement C-style explicit type conversions in CXX for matrix types

SjoerdMeijer added a comment. Perhaps for bonus points, update the Clang documentation in https://clang.llvm.org/docs/LanguageExtensions.html#matrix-types with some examples? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D101696/new/ https://revie

[PATCH] D101696: [Matrix] Implement C-style explicit type conversions in CXX for matrix types

SjoerdMeijer added a comment. In D101696#2800790 , @SaurabhJha wrote: > In D101696#2798713 , @SjoerdMeijer > wrote: > >> Perhaps for bonus points, update the Clang documentation in >> https://clang.llvm.org/doc

[PATCH] D105331: [CFE][X86] Enable complex _Float16.

SjoerdMeijer added a comment. The patch on itself looks reasonable to me. I was just wondering about the _Float16 support on X86 in general because the Clang docs says: _Float16 is currently only supported on the following targets, with further targets pending ABI standardization: Does X86

[PATCH] D98012: [RFC][doc] Document that RISC-V's __fp16 has different behavior

SjoerdMeijer added a comment. > However we would like have slight different behavior for __fp16 other than ACLE: The evaluation format of __fp16 set same as _Float16, which means no promotion are performed if there is no hardware half-precision supported. Well, this is really problematic, becaus

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: clang/lib/Basic/Targets/AArch64.cpp:363 + if (HasRandGen) +Builder.defineMacro("__ARM_FEATURE_RNG", "1"); Where/when is `HasRandGen` set? Comment at: clang/test/Preprocessor/init-aarch64.c:

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } dmgreen wrote: > SjoerdMeijer wrote: > > Do all MRS instructions do this? > No, but some do and it's

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } dmgreen wrote: > SjoerdMeijer wrote: > > dmgreen wrote: > > > SjoerdMeijer wrote: > > > > Do all MRS

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } SjoerdMeijer wrote: > dmgreen wrote: > > SjoerdMeijer wrote: > > > dmgreen wrote: > > > > SjoerdMeij

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: llvm/lib/Target/AArch64/AArch64InstrFormats.td:1495 let DecoderNamespace = "Fallback"; + let Defs = [NZCV]; } dmgreen wrote: > stelios-arm wrote: > > SjoerdMeijer wrote: > > > SjoerdMeijer wrote: > > > > dmgree

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: clang/lib/Basic/Targets/AArch64.cpp:364 + if (HasRandGen) +Builder.defineMacro("__ARM_FEATURE_RNG", "1"); + This needs a clang preprocessor test: both a check for its presence and absence. Have a look/grep wher

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer added inline comments. Comment at: clang/test/CodeGen/arm_acle.c:908 +#if __ARM_64BIT_STATE && defined(__ARM_FEATURE_RNG) +// AArch64-v8_3-LABEL: @test_rndr( +// AArch64-v8_3-NEXT: entry: stelios-arm wrote: > SjoerdMeijer wrote: > > Not sure if I am

[PATCH] D98264: [AArch64] Implement __rndr, __rndrrs intrinsics

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Thanks, nice one, LGTM. Comment at: llvm/test/CodeGen/AArch64/rand.ll:2 +; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py +; RUN: llc

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

SjoerdMeijer added a comment. This introduces another way of setting (optional) architecture extensions and having two ways to do the same is nearly always a bad thing, which is how one of my colleagues phrased it. This was already a complex area and thus I don't think introducing another is g

[PATCH] D136425: [Clang][AArch64] Add support for -mcpu=grace

This revision was automatically updated to reflect the committed changes. Closed by commit rG9ec7448857c1: [Clang][AArch64] Add support for -mcpu=grace (authored by SjoerdMeijer). Herald added a project: clang. Herald added a subscriber: cfe-commits. Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D136611: [Clang][AArch64] Add TargetParser support for defining CPU aliases

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rG9bd273047d4f: [Clang][AArch64] Add TargetParser support for defining CPU aliases (authored by SjoerdMeijer). Herald added a project: clang. Herald ad

[PATCH] D136784: [Clang] Improve diagnostic message for loop hint pragma

SjoerdMeijer added a reviewer: fhahn. SjoerdMeijer added inline comments. Comment at: clang/lib/Parse/ParsePragma.cpp:1306 StringRef Str = PragmaName.getIdentifierInfo()->getName(); + if (Str == "loop") +return (llvm::Twine("clang loop ") + Option.getIdentifierInfo()->ge

[PATCH] D136783: Pre-commit test case for D136784

SjoerdMeijer accepted this revision. SjoerdMeijer added a comment. This revision is now accepted and ready to land. Looks like a good set of extra tests to me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D136783/new/ https://reviews.llvm.org/D1367

[PATCH] D136784: [Clang] Improve diagnostic message for loop hint pragma

SjoerdMeijer added inline comments. Comment at: clang/lib/Parse/ParsePragma.cpp:1306 StringRef Str = PragmaName.getIdentifierInfo()->getName(); + if (Str == "loop") +return (llvm::Twine("clang loop ") + Option.getIdentifierInfo()->getName()).str(); eopXD

[PATCH] D76617: [SveEmitter] Fix encoding/decoding of SVETypeFlags

SjoerdMeijer added a comment. Patches with functional changes but without tests are a bit "suspicious". In this case, I see it might be tricky. You could argue that it should be incorporated in the patch that includes the tests, so we can see what's happening. But perhaps separating this out i

[PATCH] D76617: [SveEmitter] Fix encoding/decoding of SVETypeFlags

SjoerdMeijer added a comment. > Yes you're right, the patch that I've made dependent needs this one to work > properly. Ah ok, I may have missed that, will have a look Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76617/new/ https://reviews.llvm.

<    1   2   3   4   >