User Details
- User Since
- Jul 30 2019, 7:11 AM (189 w, 6 d)
Thu, Mar 16
Mon, Mar 13
Thu, Mar 9
I'm generally okay with the approach of this patch. I'm not sufficiently well-versed in the clang codegen side of things to know if this covers all of the bases, and I'd appreciate someone who is familiar with that side of things to approve this patch.
I'm studiously ignoring the Clang and LLVM codegen changes here, but otherwise, I think the direction of this change is generally good.
Wed, Mar 8
Friendly review ping?
Thu, Mar 2
Wed, Mar 1
Documentation tweaks.
Mon, Feb 27
Friendly review ping?
Thu, Feb 23
Wed, Feb 22
Thank you for adding documentation for target("aarch64.svcount"). Otherwise, the only other thing I would comment is the same thing that Nikita said with regards to the unused new methods.
Feb 17 2023
I'd ideally like to see discussion of this target extension type somewhere in documentation, but alas, AArch64 is one of the backends that lacks a dedicated target documentation page.
Mostly test fixes.
Feb 16 2023
Not entirely sure where the best place to effect this (I think somewhere in the clang driver code?), but on further reflection, it feels like strict fp-model in clang should set the denormal mode to dynamic.
Feb 14 2023
Feb 8 2023
This updates code, and rebases tests on top of trunk.
Feb 3 2023
Feb 2 2023
Looking at the attribute logic here, there is conceptual room for both a dynamic and an unknown mode (i.e., you get a top and a bottom value), but I don't think there is value in distinguishing between them, so I'm fine with keeping just a dynamic.
Feb 1 2023
Jan 27 2023
Jan 26 2023
Jan 17 2023
From some of the verifier checks and tests, it looks like target("x86.amx") would also require some new type properties, to express its unsuitability for alloca-and-friends, as well as non-intrinsic arguments.
Jan 13 2023
Jan 10 2023
Fix some of the code review comments.
Jan 5 2023
Jan 4 2023
Most of the testing for this change has been in conjunction with the changes in the SPIRV-LLVM-Translator repository here: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/1799. I haven't updated the in-tree experimental target to support the target-extension types, but I did want to provide more documentation as to how these types work in the existing LLVM documentation for the SPIR-V backend.
Dec 20 2022
There might be some cases where we can maintain some fast-math flags that would otherwise be dropped... but it's almost certainly not worth the bother here, since I expect the vast majority of cases will have all the relevant operations have the same fast-math flags.
Dec 19 2022
Fix typo in release notes.
Address review comments (and clang-format issues).
Rebase to trunk, and add release notes.
Dec 16 2022
Dec 14 2022
Documentation and test tweaks.
Dec 9 2022
Address review comments.
Dec 8 2022
I don't normally handle name mangling, so I can't comment too much here, but I will note that Itanium ABI is planning on using DF16b for std::bfloat16_t: https://github.com/itanium-cxx-abi/cxx-abi/pull/147
Dec 2 2022
Nov 30 2022
Friendly review ping?
If DAZ mode is semantically "denormals are non-canonical zero", then isfpclass(denormal, Zero) arguably should be true in DAZ mode, so lowering that to fcmp 0.0 would be legal. On the other hand, the actual lowering of an unoptimized isfpclass is likely to rely on bit patterns which would ignore the current dynamic value of DAZ. On the other other hand, there's no clear indication of what isfpclass returns for noncanonical values... and on the other other other hand, leaving the result of isfpclass as unspecified behavior for noncanonical inputs is incredibly unfriendly to users.
Rebase on trunk.
Nov 21 2022
This strikes me as correct, but I would prefer someone more expert in PowerPC specifically to comment on this.
Nov 18 2022
Nov 16 2022
Doc tweaks, name tweaks, add some verification code.
Nov 14 2022
Nov 8 2022
Nov 4 2022
Nov 3 2022
Major update.
Oct 28 2022
Oct 27 2022
Oct 26 2022
I'm similarly skeptical that this is the best way to go about the problem. Making typed pointers qualify under isPointerTy() potentially breaks a lot of code that assumes isPointerTy() means that it is indeed a PointerType, although this is ameliorated to some degree by the hard prohibition llvm::Value has on construction types with TypedPointerType.
Oct 24 2022
Oct 18 2022
Oct 17 2022
Fix some of the nits.