[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

nemanjai requested changes to this revision. nemanjai added a comment. This revision now requires changes to proceed. The finalized wording for vec_insert4b: Let W be the first doubleword element of ARG1, truncated to 32 bits. The result vector is formed by inserting W into ARG2 at the byte

[PATCH] D28528: [PowerPC] Fix the wrong implementation of builtin vec_rlnm.

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. Please fix the minor issue with the test case and then commit. LGTM. Comment at: test/CodeGen/builtins-ppc-p9vector.c:871 vector unsigned int test77(void) { +//

[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

nemanjai added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:8193 +if (getTarget().isLittleEndian()) { + // Create a shuffle mask of (1, 0) + Constant *ShuffleElts[2] = { ConstantInt::get(Int32Ty, 1), This will likely have to change when

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

nemanjai added a comment. Thank you for fixing these issues. I certainly see how the shifts really need to get the signedness right because the right shifts need to fill with the sign bit (so that vector bool will still have all 0 or all 1 bits). However, I don't really follow why the

[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

nemanjai added inline comments. Comment at: test/CodeGen/builtins-ppc-extractword-error.c:2 +// REQUIRES: powerpc-registered-target +// XFAIL: powerpc + I think this will fail on all the powerpc targets, such as powerpc64le, etc. Which isn't what you want I

[PATCH] D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. Just one minor inline nit. Other than that, LGTM. Comment at: test/CodeGen/builtins-ppc-error.c:5 +// RUN: -triple powerpc64-unknown-unknown -fsyntax-only \ +// RUN:

[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

nemanjai added a comment. @Zeson are you working on an update to this or is this to be abandoned? https://reviews.llvm.org/D27251 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D30415: Fix -mno-altivec cannot overwrite -maltivec option

nemanjai added a subscriber: echristo. nemanjai added a comment. This seems to change the relationship between -m[no-]altivec and -f[no-]altivec which has been kind of contentious for a while. Can you add a note as to whether the new behaviour matches the GCC behaviour. Also, perhaps @echristo

[PATCH] D29750: [PPC] Enable -fomit-frame-pointer by default for PPC

This revision was automatically updated to reflect the committed changes. Closed by commit rL296861: [PowerPC] Enable -fomit-frame-pointer by default for PPC (authored by nemanjai). Changed prior to commit: https://reviews.llvm.org/D29750?vs=87821=90443#toc Repository: rL LLVM

[PATCH] D36555: Move x86-specific sources to x86-specific source lists.

nemanjai added a comment. Thank you for doing this. These were causing warnings with some compilers when built on PowerPC because the sources were just empty (macro-guarded). Not compiling them at all is a much cleaner solution. LGTM but I am far from an authority on this part of the code so

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

nemanjai added a comment. Some buildbots use the distro gcc (looks like 5.4) and at least one uses gcc 7.1. I use gcc 6.2. I think that with the addition of https://reviews.llvm.org/D36555, the empty source file warnings should go away. However, I imagine that the warnings about atomics will

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

This revision was automatically updated to reflect the committed changes. Closed by commit rL309256: [PowerPC] Pass CPU to assembler with -no-integrated-as (authored by nemanjai). Changed prior to commit: https://reviews.llvm.org/D33820?vs=101508=108434#toc Repository: rL LLVM

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

nemanjai added a comment. Ping. Repository: rL LLVM https://reviews.llvm.org/D33820 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

nemanjai added a comment. This patch appears to be perfectly fine. However, it triggers a large number of warnings. Namely, there's a large number of `warning: ISO C forbids an empty translation unit [-Wpedantic]` warnings produced. The reason is that all the code in the file is wrapped with an

[PATCH] D36764: The following functions and tests work fine for powerpc64, so enable them.

nemanjai added a comment. In https://reviews.llvm.org/D36764#844486, @joerg wrote: > Because PPC uses the TC variant. Sorry, I don't understand this comment. What is the "TC variant"? https://reviews.llvm.org/D36764 ___ cfe-commits mailing list

[PATCH] D36764: The following functions and tests work fine for powerpc64, so enable them.

nemanjai added a comment. In https://reviews.llvm.org/D36764#843778, @saugustine wrote: > Anyone have any opinions on this? I don't see an issue with providing these functions on PowerPC as there doesn't seem to be anything in the implementation that PowerPC would have an issue with.

[PATCH] D33053: [PowerPC] Implement vec_xxpermdi builtin.

nemanjai requested changes to this revision. nemanjai added a comment. This revision now requires changes to proceed. Add a test case like the one that currently crashes (see inline comment). Also, please do the following: - Put a note in the description (and the commit message) with a link to

[PATCH] D33499: [PPC] PPC32/Darwin ABI info

nemanjai added subscribers: iains, echristo. nemanjai added a comment. I'm not sure how much expertise there is for PPC32-Darwin. Perhaps @iains might be able to offer some insight here. Also, @echristo might have a thing or two to say in this regard. Repository: rL LLVM

[PATCH] D33053: [PowerPC] Implement vec_xxpermdi builtin.

nemanjai added a comment. Other than the few minor comments, this LGTM. Comment at: lib/CodeGen/CGBuiltin.cpp:8458 +if (getTarget().isLittleEndian()) { + ElemIdx0 = (~Index & 1) + 2; + ElemIdx1 = (~Index & 2) >> 1; Minor nit: please add a comment

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

nemanjai updated this revision to Diff 101169. nemanjai added a comment. Initially, forgot to add a test case. Repository: rL LLVM https://reviews.llvm.org/D33820 Files: lib/Driver/ToolChains/Arch/PPC.cpp lib/Driver/ToolChains/Arch/PPC.h lib/Driver/ToolChains/Gnu.cpp

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

nemanjai created this revision. This just adds the CPU to a list of commands passed to GAS when not using the integrated assembler. Repository: rL LLVM https://reviews.llvm.org/D33820 Files: lib/Driver/ToolChains/Arch/PPC.cpp lib/Driver/ToolChains/Arch/PPC.h

[PATCH] D33981: Only print registered targets for `--version`

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. LGTM. This cleans up the failures on PPC (and probably SystemZ) so the bots should go back to green. https://reviews.llvm.org/D33981 ___

[PATCH] D33820: [PowerPC] Pass CPU to assembler with -no-integrated-as

nemanjai updated this revision to Diff 101508. nemanjai added a comment. Remove the temporary string variable for the CPU. Repository: rL LLVM https://reviews.llvm.org/D33820 Files: lib/Driver/ToolChains/Arch/PPC.cpp lib/Driver/ToolChains/Arch/PPC.h lib/Driver/ToolChains/Gnu.cpp

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

nemanjai accepted this revision. nemanjai added subscribers: hfinkel, echristo. nemanjai added a comment. This revision is now accepted and ready to land. I hope I haven't lost track of the patches that precluded this. If I remember correctly, all the X86 80-bit stuff was sorted out. We now know

[PATCH] D36764: The following functions and tests work fine for powerpc64, so enable them.

nemanjai added a comment. In https://reviews.llvm.org/D36764#844692, @joerg wrote: > divtc3 and friends. Ah, OK. I see what you mean now. These builtins are for `XCmode` calculations (complex values as two `XFmode` components). Since PPC has no support for `XFmode` (i.e. 80-bit long double)

[PATCH] D38656: [CGExprScalar] In EmitCompare trunc the result if it has different type as E->getType()

nemanjai added a comment. I assume this also fixes https://bugs.llvm.org/show_bug.cgi?id=31161? https://reviews.llvm.org/D38656 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38656: [CGExprScalar] In EmitCompare trunc the result if it has different type as E->getType()

nemanjai added a comment. In https://reviews.llvm.org/D38656#892072, @Carrot wrote: > I worked on a similar bug as 31161, and then found this one, it should be > same as in comment7. > What is the current status of the work on that bug? No one has had time to finalize a fix to it. Please go

[PATCH] D38820: [CGExprScalar] Add missing types in function GetIntrinsic

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. LGTM. https://reviews.llvm.org/D38820 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D36431: Add powerpc64 to compiler-rt build infrastructure.

nemanjai added a comment. This has been sitting in approved state for more than 2 months. As far as I can tell, it wasn't committed. Do you plan to commit this soon or are you abandoning it for some reason? https://reviews.llvm.org/D36431 ___

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

nemanjai created this revision. nemanjai added reviewers: lu-zero, hfinkel. Herald added a subscriber: kbarton. The codegen for this builtin was initially implemented to match GCC. However, due to interest from users GCC changed behaviour to account for the big endian bias of the instruction

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

nemanjai added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:10780 // endian order so the shuffle mask must be adjusted for this on little // endian platforms (i.e. index is complemented and source vector reversed). +unsigned ElemIdx0 = (Index & 2) >> 1;;

[PATCH] D49424: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does

This revision was automatically updated to reflect the committed changes. Closed by commit rC337449: [PowerPC] Handle __builtin_xxpermdi the same way as GCC does (authored by nemanjai, committed by ). Changed prior to commit: https://reviews.llvm.org/D49424?vs=155869=156251#toc Repository:

[PATCH] D48044: [Power9] Update fp128 as a valid homogenous aggregate base type

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. Other than a few style nits that can be fixed on the commit, this LGTM. Comment at: include/clang/AST/Type.h:1802 bool isFloat16Type() const; // C11 extension

[PATCH] D44921: [PowerPC] Option for secure plt mode

nemanjai added a subscriber: chmeee. nemanjai added a comment. In https://reviews.llvm.org/D44921#1056672, @spetrovic wrote: > -mbss-plt is currently default in LLVM, once secure plt support is finished > we can set secure plt as default in LLVM, but not for now. I was thinking in case the

[PATCH] D44921: [PowerPC] Option for secure plt mode

nemanjai added a comment. I'll let Justin give the actual ACK, but this looks fine to me. The only question that I have (since I don't know anything about secure PLT) is whether this is a PPC-specific thing (since the option is a PPC option). Comment at:

[PATCH] D44921: [PowerPC] Option for secure plt mode

nemanjai added a comment. In https://reviews.llvm.org/D44921#1050299, @joerg wrote: > GCC supports -mbss-plt to get the legacy behavior. Not sure if anyone > actually uses it though. @spetrovic Is this something we want to implement? https://reviews.llvm.org/D44921

[PATCH] D54087: [PowerPC] [Clang] [AltiVec] The second parameter of vec_sr function should be modulo the number of bits in the element

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. Just for clarification (and please add the text to the commit message), this is actually required by the ABI: Each element of the result vector is the result of logically right shifting

[PATCH] D53417: [Clang][Sema][PowerPC] Choose a better candidate in overload function call if there is a compatible vector conversion instead of ambiguous call error

nemanjai added a comment. @hubert.reinterpretcast Have your comments been addressed adequately in the latest version of the patch? Do you have an opinion on adding the test case I proposed? Comment at: clang/test/Sema/altivec-generic-overload.c:1 +// RUN: %clang_cc1 %s

[PATCH] D55326: [Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux

nemanjai requested changes to this revision. nemanjai added a comment. This revision now requires changes to proceed. A couple of questions since I am not all that familiar with clang and am certainly not familiar with this unusual SUSE 32-bit situation: - We seem to be changing the set of

[PATCH] D54787: [PowerPC] Vector load/store builtins overstate alignment of pointers

nemanjai created this revision. nemanjai added reviewers: hfinkel, jsji, wuzish. Herald added subscribers: kristina, kbarton. A number of builtins in altivec.h load/store vectors from pointers to scalar types. Currently they just cast the pointer to a vector pointer, but expressions like that

[PATCH] D54787: [PowerPC] Vector load/store builtins overstate alignment of pointers

This revision was automatically updated to reflect the committed changes. Closed by commit rL347556: [PowerPC] Vector load/store builtins overstate alignment of pointers (authored by nemanjai, committed by ). Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D33499: [PPC] PPC32/Darwin ABI info

nemanjai added a comment. In D33499#1341236 , @ken-cunningham-webuse wrote: > @iains - I have interest in resolving this issue, and also a couple of other > lingering bugs in the PPC32Darwin ABI realm. If you have your WIP available > anywhere, I'd be

[PATCH] D52074: [PowerPC] [Clang] Add vector int128 pack/unpack builtins

nemanjai added a comment. LGTM. Repository: rC Clang https://reviews.llvm.org/D52074 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai added a comment. In D58497#1449306 , @dblaikie wrote: > In D58497#1449243 , @nemanjai wrote: > > > Ping. > > > Unfortunately Richard Smith is out for a few weeks at the moment, so might > take a little

[PATCH] D55326: [Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux

nemanjai added a comment. Herald added a subscriber: jdoerfert. Herald added a project: clang. Do you plan to follow-up on these questions and comments? At least the full context is needed and for the test case, I imagine it can be similar to other driver test cases. I imagine

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai added a comment. Ping. If there are no objections in the next week or so, I'll commit this and it can be reviewed post-commit. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58497/new/ https://reviews.llvm.org/D58497

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. Please, no more patches without context. This one was actually easy to review without context and the comments are minor, so I'm fine with these being addressed on the commit.

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

nemanjai marked an inline comment as done. nemanjai added a comment. Herald added a subscriber: jdoerfert. Since I haven't seen any further objections to this, I'll commit this later today. Comment at: test/Preprocessor/init.c:9169 // WEBASSEMBLY-NEXT:#define __FLOAT128__ 1

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

nemanjai added a comment. In D49754#1402790 , @vit9696 wrote: > This is a series of patches, which I believe should merged altogether. > Currently the following patches are relevant: No, please don't merge them together. It is much more manageable for

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai created this revision. nemanjai added a reviewer: rsmith. Herald added a subscriber: jdoerfert. Herald added a project: clang. When the `Preprocessor (PP)` in compiler instance is going away, we should clear the cache of any pointers that it owns as they will be destroyed. This is one

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai added a comment. Ping. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58497/new/ https://reviews.llvm.org/D58497 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

This revision was automatically updated to reflect the committed changes. Closed by commit rL354512: Make predefined FLT16 macros conditional on support for the type (authored by nemanjai, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

nemanjai added a comment. Thanks Teresa, I'll commit this soon. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59304/new/ https://reviews.llvm.org/D59304 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

nemanjai created this revision. nemanjai added reviewers: xur, tejohnson, davidxl. Herald added subscribers: dexonsmith, steven_wu, inglorion, mehdi_amini. Herald added a project: clang. The above commit tries to access the parameter to the `-fprofile-use` option without checking whether the

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

nemanjai added a comment. Does anyone have any further comments or objections to this patch? I would like to commit this and close the PR. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57577/new/ https://reviews.llvm.org/D57577

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

nemanjai added a comment. There is a long series of comments in this patch and I am not clear at this point on whether this patch breaks anything or it is fine. Could you please `Request Changes` if this patch is broken or approve if it is fine? Repository: rC Clang CHANGES SINCE LAST

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

nemanjai created this revision. nemanjai added reviewers: rogfer01, bruno, ahatanak, scanon. Herald added subscribers: aheejin, jgravelle-google, sbc100, dschuff. Herald added a project: clang. We unconditionally predefine these macros. However, they may be used to determine if the type is

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

nemanjai marked an inline comment as done. nemanjai added inline comments. Comment at: lib/Basic/Targets/WebAssembly.h:55 IntPtrType = SignedLong; +HasFloat16 = true; } There are test cases that check for the macros for WebAssembly so I assumed they

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

nemanjai created this revision. nemanjai added reviewers: ilya-biryukov, jfb, takuto.ikuta, rjmccall, rsmith, SjoerdMeijer, t.p.northover, erichkeane. Herald added a subscriber: eraman. Herald added a project: clang. One of the platforms on which we do regular builds has some system headers that

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

nemanjai added a comment. In D57581#1380609 , @ilya-biryukov wrote: > ... > Do have a comment, though. Any, reason to use `-std=gnu++14` and not > `-std=c++14`? > Most (all?) of the tests do not seem to have anything to do with the gnu > extensions,

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

This revision was automatically updated to reflect the committed changes. Closed by commit rL353163: [NFC] Explicitly add -std=c++14 option to tests that rely on the C++14 default (authored by nemanjai, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits.

[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

nemanjai updated this revision to Diff 185088. nemanjai added a comment. As mentioned in a comment, the WASM tests weren't really meant to indicate that WASM supports the type. Removed the changes to the WASM target. Repository: rC Clang CHANGES SINCE LAST ACTION

[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

nemanjai updated this revision to Diff 185093. nemanjai added a comment. Changed the option to standard C++ rather than GNU extensions. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57581/new/ https://reviews.llvm.org/D57581 Files:

[PATCH] D60539: Add -std=c++14 language standard option to tests that require C++14 default

nemanjai added a comment. > Do you need to build clangd? We explicitly don't aim to support building > everywhere clang can be built, maybe we should just disable in this case? Our environment includes various OS levels running on PowerPC. We certainly wouldn't want to disable building/testing

[PATCH] D59304: Fix invocation of Gold plugin with LTO after r355331

This revision was automatically updated to reflect the committed changes. Closed by commit rL356111: Fix invocation of Gold plugin with LTO after r355331 (authored by nemanjai, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

nemanjai marked 3 inline comments as done. nemanjai added inline comments. Comment at: lib/Headers/altivec.h:16364 signed short *__ptr) { - return *(unaligned_vec_sshort *)(__ptr + __offset); + signed char *Adjusted =

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

nemanjai updated this revision to Diff 206123. nemanjai added a comment. Remove the double cast. Simplify the test case. Rename the temp. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63636/new/ https://reviews.llvm.org/D63636 Files: lib/Headers/altivec.h

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

nemanjai created this revision. nemanjai added reviewers: hfinkel, jsji, rzurob, saghir. Herald added a subscriber: kbarton. Herald added a project: clang. As we currently have it implemented in altivec.h, the offsets for these two intrinsics are element offsets. The documentation in the ABI (as

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai added a comment. Herald added a subscriber: jsji. Ping. Does anyone think this is a good idea? Bad idea? Have any further comments? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58497/new/ https://reviews.llvm.org/D58497

[PATCH] D64024: [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne

nemanjai created this revision. nemanjai added reviewers: hfinkel, jsji, rzurob. Herald added subscribers: kristina, kbarton. Herald added a project: clang. We currently emit a double precision comparison instruction for this, whereas we need to emit the single precision version. Repository:

[PATCH] D58497: Clear the KnownModules cache if the preprocessor is going away

nemanjai added a comment. I have not seen this problem resurface to be honest. When we initially hit it, changing the path for the build worked around the problem for us so we weren't really hitting in any longer. I posted this because I realized the possibility exists of having these dangling

[PATCH] D64024: [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne

This revision was automatically updated to reflect the committed changes. Closed by commit rG070e4027b024: [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne (authored by nemanjai). Changed prior to commit: https://reviews.llvm.org/D64024?vs=207374=228354#toc Repository:

[PATCH] D63636: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst

This revision was automatically updated to reflect the committed changes. Closed by commit rGe0407f549653: [PowerPC][Altivec] Fix offsets for vec_xl and vec_xst (authored by nemanjai). Herald added subscribers: shchenz, wuzish. Changed prior to commit:

[PATCH] D64024: [PowerPC][Altivec] Emit correct builtin for single precision vec_all_ne

nemanjai added a comment. Herald added subscribers: shchenz, wuzish. In D64024#1565190 , @jsji wrote: > LGTM. > BTW, looks like we are missing test cases all `vector float` `vec_all*` and > `vec_any*` and also non-vsx path? The non-VSX path is tested

[PATCH] D55326: [Driver] Fix incorrect GNU triplet for PowerPC on SUSE Linux

nemanjai accepted this revision. nemanjai added a comment. LGTM. Thanks for adding the test case. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55326/new/ https://reviews.llvm.org/D55326 ___

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

nemanjai added a comment. > You're right, -O0 shouldn't generate FMA. I'm preparing to revert this now -- > just verifying the build. Perhaps this should be `off` with no optimization `on` with `-O1/-O2/-O3/-Os/-Oz` `fast` with fast math Just a suggestion, I'm not sure whether that would be

[PATCH] D72579: Evaluate __{c11_,}atomic_is_lock_free to 0 (avoid libcall) if larger than MaxAtomicPromoteWidth

nemanjai added a comment. If I understand this correctly, this just evaluates the query for lock free atomics at compile time if the size is larger than the maximum possible size for an atomic on the target. If that's the case, this looks fine to me. But of course, some of the other target

[PATCH] D71600: PowerPC 32-bit - forces 8 byte lock/lock_free decisions at compiled time

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. LGTM. Comment at: clang/lib/AST/ExprConstant.cpp:11028 +// The lock free possibilities on this platform are covered by the lines +// above and we know in

[PATCH] D78308: [NFC][PowerPC] Refactor ppcUserFeaturesCheck()

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

[PATCH] D77085: [clang-tidy] Added support for validating configuration options

nemanjai added a comment. In D77085#1967864 , @njames93 wrote: > In D77085#1967807 , @nemanjai wrote: > > > A recent commit has taken down a whole bunch of bots. The build error > > messages all seem to point to

[PATCH] D77085: [clang-tidy] Added support for validating configuration options

nemanjai added a comment. Herald added a subscriber: wuzish. A recent commit has taken down a whole bunch of bots. The build error messages all seem to point to code in this patch. If this is indeed the cause, please revert. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D73290: [PowerPC] Add clang -msvr4-struct-return for 32-bit ELF

nemanjai accepted this revision. nemanjai added a comment. Aside from a couple of minor nits that shouldn't require another review, LGTM. Comment at: clang/docs/ClangCommandLineReference.rst:2631 + +Override the default ABI for 32-bit targets to return small structs in

[PATCH] D77249: [MSan] Pass command line options to MSan with new pass manager

nemanjai marked an inline comment as done. nemanjai added inline comments. Comment at: compiler-rt/test/msan/chained_origin_empty_stack_npm.cpp:4 +// this test. +// RUN: %clangxx_msan -fsanitize-memory-track-origins=2 \ +// RUN: -fexperimental-new-pass-manager -O3 %s -o %t

[PATCH] D77249: [MSan] Pass command line options to MSan with new pass manager

nemanjai marked an inline comment as done. nemanjai added inline comments. Comment at: compiler-rt/test/msan/chained_origin_empty_stack_npm.cpp:4 +// this test. +// RUN: %clangxx_msan -fsanitize-memory-track-origins=2 \ +// RUN: -fexperimental-new-pass-manager -O3 %s -o %t

[PATCH] D77249: [MSan] Pass command line options to MSan with new pass manager

nemanjai created this revision. nemanjai added reviewers: eugenis, vitalybuka, philip.pfaffe, leonardchan, PowerPC. Herald added projects: clang, Sanitizers. Herald added subscribers: Sanitizers, cfe-commits. There are a number of test cases that fail when clang is built to use NPM by default.

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

nemanjai created this revision. nemanjai added reviewers: hfinkel, PowerPC. Herald added subscribers: cfe-commits, shchenz, kbarton. Herald added a project: clang. We currently emit incorrect codegen for this constraint because we set it as a constraint that allows registers. This will cause the

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

nemanjai marked an inline comment as done. nemanjai added inline comments. Comment at: clang/lib/Basic/Targets/PPC.h:277 break; case 'Q': // Memory operand that is an offset from a register (it is // usually better to use `m' or `es' in asm statements)

[PATCH] D80374: [Clang] Enable KF and KC mode for [_Complex] __float128

nemanjai created this revision. nemanjai added reviewers: rjmccall, rsmith, PowerPC, hfinkel. Herald added subscribers: dexonsmith, kbarton. Herald added a reviewer: aaron.ballman. Herald added a project: clang. The headers provided with recent GNU toolchains for PPC have code that includes

[PATCH] D80300: [Driver] Add DEFAULT_DYLD_PREFIX and DEFAULT_RPATH to complement DEFAULT_SYSROOT

nemanjai accepted this revision. nemanjai added subscribers: tstellar, brad, craig.topper, joerg. nemanjai added a comment. This revision is now accepted and ready to land. Thank you for sorting this out. I think it is quite useful to be able to configure the compiler to use complete

[PATCH] D80294: Add support for vmsumudm

nemanjai accepted this revision. nemanjai added a comment. This revision is now accepted and ready to land. LGTM. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80294/new/ https://reviews.llvm.org/D80294 ___ cfe-commits mailing list

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

nemanjai marked an inline comment as done. nemanjai added inline comments. Comment at: clang/test/CodeGen/ppc64-inline-asm.c:50 +// CHECK-LABEL: void @testZwOff(i8* %addr, i64 %off) +// CHEC: %[[VAL:[^ ]+]] = getelementptr i8, i8* %addr, i64 %off +// CHEC: call void asm

[PATCH] D77542: [PowerPC] Treat 'Z' inline asm constraint as a true memory constraint

This revision was automatically updated to reflect the committed changes. Closed by commit rGaede24ecaa08: [PowerPC] Treat Z inline asm constraint as a true memory constraint (authored by nemanjai). Changed prior to commit: https://reviews.llvm.org/D77542?vs=255291=265730#toc Repository: rG

[PATCH] D82485: Add tests for sequences of callbacks that RecursiveASTVisitor produces

nemanjai added a comment. Is there a way this test case can somehow be broken up into multiple files? The test case takes a very long time to compile which causes intermittent but frequent failures on one of our bots that runs on a fairly small VM. Most of the failures listed here:

[PATCH] D87321: Fix -gz=zlib options for linker

nemanjai added a comment. This broke the PPC LLD bot and the failure has been ignored for 4 days. I believe it should be fixed with 3bc3983f229 . Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D84962: [PowerPC] Correct cpsgn's behaviour on PowerPC to match that of the ABI

nemanjai added a comment. Yes, this definitely needs a test case. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84962/new/ https://reviews.llvm.org/D84962 ___ cfe-commits mailing list

[PATCH] D86819: [PowerPC][Power10] Implementation of 128-bit Binary Vector Rotate builtins

nemanjai added inline comments. Comment at: clang/lib/Headers/altivec.h:7743 + return __builtin_altivec_vrlqnm(__a, ((__c << ShiftMask) | +(__b << ShiftRotation))); +} While correct, this implementation will require two

[PATCH] D84962: [PowerPC] Correct cpsgn's behaviour on PowerPC to match that of the ABI

nemanjai added inline comments. Comment at: clang/test/CodeGen/builtins-ppc-vsx.c:1 -// REQUIRES: powerpc-registered-target +// requires: powerpc-registered-target // RUN: %clang_cc1 -target-feature +altivec -target-feature +vsx -triple powerpc64-unknown-unknown -emit-llvm %s

[PATCH] D82485: Add tests for sequences of callbacks that RecursiveASTVisitor produces

nemanjai added a comment. Hi @gribozavr do you think we can do something about this test? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82485/new/ https://reviews.llvm.org/D82485 ___ cfe-commits mailing

[PATCH] D88154: Initial support for vectorization using Libmvec (GLIBC vector math library).

nemanjai added inline comments. Comment at: llvm/include/llvm/Analysis/TargetLibraryInfo.h:91 Accelerate, // Use Accelerate framework. +LIBMVEC,// GLIBC Vector Math library. MASSV, // IBM MASS vector library. fpetrogalli wrote: > Can we

[PATCH] D82502: [PowerPC] Implement Load VSX Vector and Sign Extend and Zero Extend

nemanjai accepted this revision. nemanjai added a comment. LGTM aside from a couple of minor nits. Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:13405 + // This combine is only eligible for a BUILD_VECTOR of v1i128. + // Other return types are not valid for the

  1   2   3   4   >