[PATCH] D142947: [hexagon] add a -mcabac flag

kparzysz accepted this revision. kparzysz added a comment. This revision is now accepted and ready to land. The cxx tests passed for me. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142947/new/ https://reviews.llvm.org/D142947 ___

[PATCH] D140757: [Hexagon][VE][WebAssembly] Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP macros

kparzysz accepted this revision. kparzysz added a comment. This revision is now accepted and ready to land. All of Hexagon's atomics are implemented using load-locked/store-conditional. If that meets the expectations of these macros, then this is fine with me. Repository: rG LLVM Github Mono

[PATCH] D131172: [clang][llvm][doc] Add more information for the ABI change in FP16

kparzysz accepted this revision. kparzysz added a comment. This revision is now accepted and ready to land. Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D131172/new/ https://reviews.llvm.org/D131172

[PATCH] D125177: Recognize scope of thread local variables in CFGBuilder

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGd9e6b5df74f5: [clang] Recognize scope of thread local variables in CFGBuilder (authored by kparzysz). Repository: rG LLVM Github Monorepo CHANGES

[PATCH] D125177: Recognize scope of thread local variables in CFGBuilder

kparzysz updated this revision to Diff 427939. kparzysz added a comment. Use the proper diff file this time. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125177/new/ https://reviews.llvm.org/D125177 Files: clang/lib/Analysis/CFG.cpp clang/tes

[PATCH] D125177: Recognize scope of thread local variables in CFGBuilder

kparzysz updated this revision to Diff 427938. kparzysz added a comment. Replace the direct storage class examination with `hasLocalStorage`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125177/new/ https://reviews.llvm.org/D125177 Files: clang

[PATCH] D125177: Recognize scope of thread local variables in CFGBuilder

kparzysz created this revision. kparzysz added a reviewer: rsmith. Herald added subscribers: pengfei, krytarowski, arichardson, emaste. Herald added a project: All. kparzysz requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Compiling the foll

[PATCH] D113638: [xray] Add support for hexagon architecture

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

[PATCH] D111529: Specify Clang vector builtins.

kparzysz added inline comments. Comment at: clang/docs/LanguageExtensions.rst:553 +Each builtin returns a scalar equivalent to applying the specified +operation(x, y) as horizontal recursive pairwise reduction to all vector +elements. In each reduction step, ``operation(x, y)`` i

[PATCH] D75638: [Hexagon] Support for Linux/Musl ABI.

kparzysz added a comment. I'm not sure if it's worth defining these macros especially if this is the only place where they are used. We'd need a more coordinated effort to replace all 32's with named constants where it refers to a register size, and I'm not even sure if we could classify wheth

[PATCH] D70919: [Hexagon] Avoid passing unsupported options to lld when -fuse-ld=lld is used

kparzysz added inline comments. Comment at: clang/test/Driver/hexagon-toolchain-elf.c:560 +// CHECK082-NOT: "-march=hexagon" +// CHECK082-NOT: "-mcpu=hexagon" kparzysz wrote: > I don't think there will ever be `"-mcpu=hexagon"` (including the quotation

[PATCH] D70919: [Hexagon] Avoid passing unsupported options to lld when -fuse-ld=lld is used

kparzysz added inline comments. Comment at: clang/test/Driver/hexagon-toolchain-elf.c:560 +// CHECK082-NOT: "-march=hexagon" +// CHECK082-NOT: "-mcpu=hexagon" I don't think there will ever be `"-mcpu=hexagon"` (including the quotation marks). Maybe thi

[PATCH] D62127: [Hexagon] driver uses out-of-date option name and binary name

This revision was automatically updated to reflect the committed changes. Closed by commit rL364648: [Hexagon] driver uses out-of-date option name and binary name (authored by kparzysz, committed by ). Herald added a project: LLVM. Herald added a subscriber: llvm-commits. Changed prior to commit:

[PATCH] D59168: [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and include/c++

kparzysz added a comment. This commit stopped clang++ from finding libc++: main.cc: #include int main() { std::vector x; return x.size(); } $ clang++ main.cc -stdlib=libc++ -v clang version 9.0.0 (/w/src/llvm.org/tools/clang 754813c4737a444eeb4ea5b4070073dd251504cc) (/w

[PATCH] D52840: Include Python binding tests in CMake rules

kparzysz added a comment. Hexagon clang builder has been failing since around the time of this commit as well: http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/20617/steps/ninja%20check%201/logs/stdio Repository: rC Clang https://reviews.llvm.org/D52840 _

[PATCH] D48571: improve diagnostics for missing 'template' keyword

kparzysz added a comment. Please take over, I commandeered to restore the patch. Repository: rL LLVM https://reviews.llvm.org/D48571 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit

[PATCH] D48571: improve diagnostics for missing 'template' keyword

kparzysz updated this revision to Diff 152946. kparzysz added a comment. Restored the original patch. Repository: rL LLVM https://reviews.llvm.org/D48571 Files: include/clang/Basic/BitmaskEnum.h include/clang/Parse/Parser.h include/clang/Parse/RAIIObjectsForParser.h include/clang/Sem

[PATCH] D48571: improve diagnostics for missing 'template' keyword

kparzysz reopened this revision. kparzysz added a comment. This needs to be restored to the original form. A mistake in a commit message closed this review by accident. Repository: rL LLVM https://reviews.llvm.org/D48571 ___ cfe-commits mailing

[PATCH] D38548: Hexagon] Move getHexagonTargetFeatures to Hexagon.cpp (NFC)

kparzysz accepted this revision. kparzysz added a comment. This revision is now accepted and ready to land. Thanks! Repository: rL LLVM https://reviews.llvm.org/D38548 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/

[PATCH] D36712: Emit section information for extern variables

kparzysz added a comment. The problem is that the mismatch between sections does not have to lead to any undesirable behavior. Whether it does or not depends on a particular case. I think we should be consistent though---if we decide that a mismatch between the section for a declaration and t

[PATCH] D36712: Emit section information for extern variables

kparzysz added a comment. In https://reviews.llvm.org/D36712#843387, @eandrews wrote: > Does this result in unexpected behavior though? Won't this just result in the > global being defined in the specified section? If there is no section given explicitly, there is function SelectSectionForGlo

[PATCH] D36712: Emit section information for extern variables

kparzysz added a comment. In https://reviews.llvm.org/D36712#842433, @efriedma wrote: > I can't see how "undefined behavior" could possibly be the right answer in > that case. Every definition has to end up in some section eventually, and in > many cases we don't know what section that will be

[PATCH] D36712: Emit section information for extern variables

kparzysz added inline comments. Comment at: docs/LangRef.rst:629 +corresponding to the LLVM module, section information specified in the +declaration is retained in LLVM IR to enable OpenCL processes. + sdardis wrote: > efriedma wrote: > > This doesn't really ex

[PATCH] D35577: Add -flookup-tables and -fno-lookup-tables flags

kparzysz added a comment. In https://reviews.llvm.org/D35577#817944, @echristo wrote: > "Should this just be part of the tuning for the hexagon backend and not > options at all" The ultimate decision as to what kind of code to generate out of a switch statement belongs to the customer. The r

[PATCH] D35578: Add -fswitch-tables and -fno-switch-tables flags

kparzysz added a comment. In https://reviews.llvm.org/D35578#814919, @mcrosier wrote: > It sounds like to me you have some cases when you do want lookup tables and > other cases that you don't. What exactly is the determining factor here? The determining factor is whether the customers want i

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

kparzysz added a comment. Great! Thanks. Repository: rL LLVM https://reviews.llvm.org/D33499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

kparzysz added a comment. Ping. The bug reporter has verified that this patch fixes the problem. Repository: rL LLVM https://reviews.llvm.org/D33499 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/li

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

kparzysz updated this revision to Diff 100720. kparzysz retitled this revision from "[PPC] First approximation of PPC32/Darwin ABI info" to "[PPC] PPC32/Darwin ABI info". kparzysz edited the summary of this revision. kparzysz added a comment. This patch corrects the ABI alignment issues for argum

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

This revision was automatically updated to reflect the committed changes. Closed by commit rL303851: [CodeGen] Pessimize aliasing for member unions (and may-alias) objects (authored by kparzysz). Changed prior to commit: https://reviews.llvm.org/D33328?vs=100142&id=100232#toc Repository: rL

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz updated this revision to Diff 100142. kparzysz added a comment. Pass char TBAA directly to DecorateInstructionWithTBAA and pass true for ConvertTypeToTag in such cases. Repository: rL LLVM https://reviews.llvm.org/D33328 Files: lib/CodeGen/CGExpr.cpp test/CodeGen/union-tbaa1.c

[PATCH] D33499: [PPC] First approximation of PPC32/Darwin ABI info

kparzysz updated this revision to Diff 100105. kparzysz added a comment. Add implementation of EmitVAArg and explicitly call emitVoidPtrVAArg in it. Repository: rL LLVM https://reviews.llvm.org/D33499 Files: lib/CodeGen/TargetInfo.cpp Index: lib/CodeGen/TargetInfo.cpp ===

[PATCH] D33499: [PPC] First approximation of PPC32/Darwin ABI info

kparzysz created this revision. Use the default implementation of EmitVAArg instead of the SVR4 one. This is meant to address PR33108. This is really just a scaffold. I don't know what exactly needs to be implemented for Darwin. The motivating testcase: void foo() { __builtin_va_list

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:1436 +if (BaseInfo.getMayAlias()) + TBAAInfo = CGM.getTBAAInfo(getContext().CharTy); llvm::MDNode *TBAAPath = CGM.getTBAAStructTagInfo(TBAABaseType, TBAAInfo, rjmccall wrote: > kparz

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:1436 +if (BaseInfo.getMayAlias()) + TBAAInfo = CGM.getTBAAInfo(getContext().CharTy); llvm::MDNode *TBAAPath = CGM.getTBAAStructTagInfo(TBAABaseType, TBAAInfo, rjmccall wrote: > Hmm.

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz updated this revision to Diff 99939. kparzysz added a comment. Checking for offset 0 in the TBAA info. Repository: rL LLVM https://reviews.llvm.org/D33328 Files: lib/CodeGen/CGExpr.cpp test/CodeGen/union-tbaa1.c test/CodeGenCXX/union-tbaa2.cpp Index: test/CodeGenCXX/union-tba

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz added inline comments. Comment at: test/CodeGen/union-tbaa1.c:44 +// CHECK: ![[CHAR:[0-9]+]] = !{!"omnipotent char" +// CHECK: ![[OCPATH]] = !{![[CHAR]] hfinkel wrote: > Please check the path offset? What needs to be checked exactly? The offset will be

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz updated this revision to Diff 99918. kparzysz edited the summary of this revision. kparzysz added a comment. Previously, the variable mayAlias in EmitLValueForField could have been false even if the base LValue had may-alias flag set. Make sure that mayAlias reflects the base aliasing.

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz marked an inline comment as done. kparzysz added inline comments. Comment at: cfe/trunk/lib/CodeGen/CodeGenFunction.h:3756 /// /// \param Source - If non-null, this will be initialized with /// information about the source of the alignment. Note that this ---

[PATCH] D33328: [CodeGen] Pessimize aliasing for union members (and may-alias) objects

kparzysz updated this revision to Diff 99467. kparzysz edited subscribers, added: cfe-commits; removed: llvm-commits. kparzysz added a comment. The diff is the same as before, the change is in the subscribers: from llvm-commits to cfe-commits. Repository: rL LLVM https://reviews.llvm.org/D33

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz abandoned this revision. kparzysz added a comment. This review is replaced by https://reviews.llvm.org/D33328. Repository: rL LLVM https://reviews.llvm.org/D31885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

This revision was automatically updated to reflect the committed changes. Closed by commit rL303358: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource (authored by kparzysz). Changed prior to commit: https://reviews.llvm.org/D33284?vs=99353&id=99457#toc Repository: rL LLVM https

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz added a comment. If you have no further comments, could you accept this review? Repository: rL LLVM https://reviews.llvm.org/D33284 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cf

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz updated this revision to Diff 99353. kparzysz marked 2 inline comments as done. kparzysz added a comment. Changed the getNatural.*TypeAlignment to produce the entire LValueBaseInfo, assuming MayAlias to be false. Added merging of LValueBaseInfos. The merging assumes that the alignment

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:2256 Address(CapLVal.getPointer(), getContext().getDeclAlign(VD)), -CapLVal.getType(), AlignmentSource::Decl); +CapLVal.getType(), LValueBaseInfo(AlignmentSource::Decl, MayAli

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. I posted https://reviews.llvm.org/D33284 for the change from AlignmentSource to LValueBaseInfo. Repository: rL LLVM https://reviews.llvm.org/D31885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.ll

[PATCH] D33284: [CodeGen] Propagate LValueBaseInfo instead of AlignmentSource

kparzysz created this revision. The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. Thi

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. In https://reviews.llvm.org/D31885#751164, @rjmccall wrote: > The right fix is probably just to make sure that EmitLValueForField doesn't > add TBAA information when the base LValue doesn't have it. That will also > fix problems with recursive member access where the

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. I'm not intimately familiar with clang, so if you know about a better place for doing this, please let me know. Repository: rL LLVM https://reviews.llvm.org/D31885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. In https://reviews.llvm.org/D31885#748889, @rjmccall wrote: > Sounds to me like we should just not apply struct-path TBAA data that runs > through a union field because either LLVM's representation can't handle it or > Clang isn't generating the representation right.

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. Ping. What's the next step here? Repository: rL LLVM https://reviews.llvm.org/D31885 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz updated this revision to Diff 95780. kparzysz added a comment. Memoize known results of checking for union access. Repository: rL LLVM https://reviews.llvm.org/D31885 Files: lib/CodeGen/CGExpr.cpp lib/CodeGen/CodeGenFunction.cpp lib/CodeGen/CodeGenFunction.h test/CodeGen/uni

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. In https://reviews.llvm.org/D31885#730038, @hfinkel wrote: > I'm somewhat concerned that this patch is quadratic in the AST. I'd be happy to address this, but I'm not sure how. Memoizing results could be one way, but don't know if that's acceptable. This location in

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. I'm not really concerned about the approach here---I can abandon this patch if you have something better. You have two testcases. One is based on an issue that our customer encountered. As long as TBAA doesn't produce false negatives, it's all good. Repository:

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added a comment. This is not meant as a fine-grained solution to the TBAA problem, but a temporary fix for generating wrong information. Just yesterday I helped diagnose yet another problem related to this, so this issue is causing trouble out there. Repository: rL LLVM https://r

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz updated this revision to Diff 95217. kparzysz edited the summary of this revision. kparzysz added a reviewer: hfinkel. kparzysz added a comment. Fixed the testcases (forgot to use FileCheck). Repository: rL LLVM https://reviews.llvm.org/D31885 Files: lib/CodeGen/CGExpr.cpp lib/C

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz updated this revision to Diff 94721. kparzysz added a comment. Cleaned the code up, added testcases. Repository: rL LLVM https://reviews.llvm.org/D31885 Files: lib/CodeGen/CGExpr.cpp lib/CodeGen/CodeGenFunction.h test/CodeGen/union-tbaa1.c test/CodeGenCXX/union-tbaa2.cpp In

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz created this revision. The TBAA information for union members may be wrong, and in the current form TBAA cannot represent them correctly. This is a follow-up to this thread from llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-April/111859.html Repository: rL LLVM https://re

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz added inline comments. Comment at: lib/CodeGen/CGExpr.cpp:1019 +/// optimizations). +static bool isUnionAccess(const Expr *E) { + switch (E->getStmtClass()) { I'm not sure if this is a complete list of different ways to get a union member. Repository:

[PATCH] D31885: Remove TBAA information from LValues representing union members

kparzysz updated this revision to Diff 94699. kparzysz added a comment. Do not stop the check for unions at the first MemberExpr (unless it's a union). Repository: rL LLVM https://reviews.llvm.org/D31885 Files: lib/CodeGen/CGExpr.cpp Index: lib/CodeGen/CGExpr.cpp =

[PATCH] D25811: [libcxx] Fix toupper/tolower tests for UTF-8 locale

kparzysz abandoned this revision. kparzysz added a comment. In https://reviews.llvm.org/D25811#632670, @EricWF wrote: > While I was attempting to review this patch I ended up coming up with fixed > tests myself. I committed them in r290746. I'm very sorry to step on your > toes. No problem at