Re: r270962 - [OPENMP] Fixed processing of '-fopenmp-version=' option and test.

Hi, Alexey, At what point can we switch, by default, to reporting a version for _OPENMP corresponding to 4.x? We're missing out on some OpenMP simd directives because the source code guards them with '#if _OPENMP >= 201307' or similar. Thanks again, Hal On 05/26/2016 11:13 PM, Alexey Bataev

Re: r270962 - [OPENMP] Fixed processing of '-fopenmp-version=' option and test.

On 10/02/2017 07:08 PM, Alexey Bataev wrote: Hi Hal, As soon as we get the support for 4.5, including offloading. Otherwise there always are going to be some people blaming the compiler for not supporting 4.5 in full. Will try to support it ASAP. Meanwhile, you can use -fopenmp-version=45 opt

Re: r270962 - [OPENMP] Fixed processing of '-fopenmp-version=' option and test.

On 10/02/2017 07:38 PM, Alexey Bataev wrote: No, there is no such page. We parse everything from 4.5, but have very limited support in codegen for target-specific directives, especially combined one. Moreover, some of them are not implemented at all and we may produce incorrect code. I can try

Re: Attribute spelling policy

On 10/21/2017 10:14 AM, Aaron Ballman via cfe-commits wrote: Attributes come with multiple spelling flavors, but when it comes to adding new attributes that are not present in other compiler tools such as GCC or MSVC, we have done a poor job of being consistent with which spelling flavors we ado

Re: r336467 - [OPENMP] Fix PR38026: Link -latomic when -fopenmp is used.

On 07/16/2018 01:19 PM, Jonas Hahnfeld wrote: > [ Moving discussion from https://reviews.llvm.org/D49386 to the > relevant comment on cfe-commits, CC'ing Hal who commented on the > original issue ] > > Is this change really a good idea? It always requires libatomic for > all OpenMP applications, e

Re: r336467 - [OPENMP] Fix PR38026: Link -latomic when -fopenmp is used.

On 07/19/2018 09:01 AM, Jonas Hahnfeld wrote: > On 2018-07-19 15:43, Hal Finkel wrote: >> On 07/16/2018 01:19 PM, Jonas Hahnfeld wrote: >>> [ Moving discussion from https://reviews.llvm.org/D49386 to the >>> relevant comment on cfe-commits, CC'ing Hal who commented on the >>> original issue ] >>>

r320904 - [TextDiagnosticBuffer] Fix diagnostic note emission order

Author: hfinkel Date: Fri Dec 15 17:40:19 2017 New Revision: 320904 URL: http://llvm.org/viewvc/llvm-project?rev=320904&view=rev Log: [TextDiagnosticBuffer] Fix diagnostic note emission order The frontend currently groups diagnostics from the command line according to diagnostic level, but that p

r320908 - [VerifyDiagnosticConsumer] support -verify=

Author: hfinkel Date: Fri Dec 15 18:23:22 2017 New Revision: 320908 URL: http://llvm.org/viewvc/llvm-project?rev=320908&view=rev Log: [VerifyDiagnosticConsumer] support -verify= This mimics FileCheck's --check-prefixes option. The default prefix is "expected". That is, "-verify" is equivalent to

Re: r321239 - Fix for PR32990

On 12/20/2017 08:07 PM, Erich Keane via cfe-commits wrote: Author: erichkeane Date: Wed Dec 20 18:07:46 2017 New Revision: 321239 URL: http://llvm.org/viewvc/llvm-project?rev=321239&view=rev Log: Fix for PR32990 This fixes the bug in https://bugs.llvm.org/show_bug.cgi?id=32990. Too late now,

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 08/22/2017 10:56 PM, Wei Mi via llvm-commits wrote: On Tue, Aug 22, 2017 at 7:03 PM, Xinliang David Li wrote: On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator wrote: chandlerc added a comment. I'm really not a fan of the degree of complexity and subtlety that this intro

r312447 - [CodeGen] Treat all vector fields as mayalias

Author: hfinkel Date: Sun Sep 3 10:18:25 2017 New Revision: 312447 URL: http://llvm.org/viewvc/llvm-project?rev=312447&view=rev Log: [CodeGen] Treat all vector fields as mayalias Because it is common to treat vector types as an array of their elements, or even some other type that's not the elem

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 03:44 PM, Wei Mi wrote: On Sat, Sep 2, 2017 at 6:04 PM, Hal Finkel wrote: On 08/22/2017 10:56 PM, Wei Mi via llvm-commits wrote: On Tue, Aug 22, 2017 at 7:03 PM, Xinliang David Li wrote: On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator wrote: chandlerc adde

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 10:38 PM, Xinliang David Li wrote: Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while the store forwarding stalls cost about 10 cycles more than a successful store forwarding, which i

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 11:06 PM, Xinliang David Li wrote: I think we can think this in another way. For modern CPU architectures which supports store forwarding with store queues, it is generally not "safe" to blindly do local optimizations to widen the load/stores Why not widen stores? Generally th

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/04/2017 12:12 AM, Xinliang David Li wrote: On Sun, Sep 3, 2017 at 9:23 PM, Hal Finkel > wrote: On 09/03/2017 11:06 PM, Xinliang David Li wrote: I think we can think this in another way. For modern CPU architectures which supports store forwarding

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/03/2017 11:22 PM, Wei Mi wrote: On Sun, Sep 3, 2017 at 8:55 PM, Hal Finkel wrote: On 09/03/2017 10:38 PM, Xinliang David Li wrote: Store forwarding stall cost is usually much higher compared with a load hitting L1 cache. For instance, on Haswell, the latter is ~4 cycles, while the stor

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 09/04/2017 03:57 AM, Chandler Carruth wrote: On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits mailto:llvm-comm...@lists.llvm.org>> wrote: Nevertheless, I think that you've convinced me that this is a least-bad solution. I'll want a flag preserving the old behavior. So

Re: D37042: Teach clang to tolerate the 'p = nullptr + n' idiom used by glibc

On 09/22/2017 01:09 PM, Kaylor, Andrew wrote: The reason I introduced this patch to begin with is that there are circumstances under which the optimizer will eliminate loads from addresses that were generated based on the null pointer arithmetic (because clang previously emitted a null-based

Re: D37042: Teach clang to tolerate the 'p = nullptr + n' idiom used by glibc

On 09/22/2017 01:45 PM, Sylvestre Ledru wrote: On 22/09/2017 20:27, Hal Finkel wrote: On 09/22/2017 01:09 PM, Kaylor, Andrew wrote: The reason I introduced this patch to begin with is that there are circumstances under which the optimizer will eliminate loads from addresses that were ge

Re: [PATCH] D48808: [CodeGen] Emit parallel_loop_access for each loop in the loop stack.

On 07/02/2018 12:27 PM, Tyler Nowicki wrote: > Hi Michael, Hal, > > Sorry it has been a while since I looked at this. My memory is a > little fuzzy. The intent of 'assume_safety' is to tell LAA to > skip dependency checking on loads and stores so the vectorizer doesn't > stop as soon as it sees bo

Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

We currently have logic in the test suite that sets -ffp-contract=off on PowerPC (because the default for GCC and other compilers on PowerPC/Linux systems is essentially -ffp-contract=fast). We might just want to do this now for all platforms. -Hal - Original Message - > From: "Steve

Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.

- Original Message - > From: "George Burgess IV" > To: "Hal Finkel" > Cc: "Richard Smith" , "Joerg Sonnenberger" > , "cfe-commits" > > Sent: Monday, September 19, 2016 11:21:33 PM > Subject: Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks. > > > WFM; I'll put toge

Re: r282426 - CC1: Add -save-stats option

Nice! -Hal - Original Message - > From: "Matthias Braun via cfe-commits" > To: cfe-commits@lists.llvm.org > Sent: Monday, September 26, 2016 1:53:34 PM > Subject: r282426 - CC1: Add -save-stats option > > Author: matze > Date: Mon Sep 26 13:53:34 2016 > New Revision: 282426 > > URL: h

Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. A nice abstraction and cleanup. LGTM. Comment at: lib/Driver/Driver.cpp:1625 @@ +1624,3 @@ + // architecture. If we are in host-only mode we return 'success' so that +

Re: [PATCH] D21840: [Driver][CUDA][OpenMP] Reimplement tool selection in the driver.

hfinkel added a comment. The naming here is a bit hard to follow, we have 'dependent action', 'dependency action', 'depending action', and I think they're all supposed to mean the same thing. Only 'dependent action' sounds right to me, can we use that universally (i.e. in all comments and names

Re: [PATCH] D21843: [Driver][OpenMP] Create tool chains for OpenMP offloading kind.

hfinkel added inline comments. Comment at: include/clang/Basic/DiagnosticDriverKinds.td:163 @@ +162,3 @@ +def err_drv_expecting_fopenmp_with_fopenmp_targets : Error< + "The option -fopenmp-targets must be used in conjunction with a -fopenmp option compatible with offloading.">;

Re: [PATCH] D21845: [Driver][OpenMP] Add specialized action builder for OpenMP offloading actions.

hfinkel added inline comments. Comment at: lib/Driver/Driver.cpp:1836 @@ +1835,3 @@ +ActionBuilderReturnCode +getDeviceDepences(OffloadAction::DeviceDependences &DA, phases::ID CurPhase, + phases::ID FinalPhase, PhasesTy &Phases) override { --

Re: [PATCH] D21847: [Driver][OpenMP] Build jobs for OpenMP offloading actions for targets using gcc tool chains.

hfinkel added inline comments. Comment at: lib/Driver/Tools.cpp:243 @@ +242,3 @@ +// ignore inputs that refer to OpenMP offloading devices - they will be +// embedded recurring to a proper linker script. +if (auto *IA = II.getAction()) recurring -> acc

Re: [PATCH] D21848: [Driver][OpenMP] Add logic for offloading-specific argument translation.

hfinkel added inline comments. Comment at: lib/Driver/ToolChains.cpp:2834 @@ +2833,3 @@ + // If this tool chain is used for an OpenMP offloading device we have to make + // sure we always generate a shared library regardless the commands the user + // passed to the host. This i

Re: [PATCH] D21852: [Driver][OpenMP] Update actions builder to create bundling action when necessary.

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D21852 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

Re: [PATCH] D21853: [Driver][OpenMP] Update actions builder to create unbundling action when necessary.

hfinkel added inline comments. Comment at: include/clang/Driver/Action.h:504 @@ +503,3 @@ + /// unbundling action. + struct DependingActionInfoTy final { +/// \brief The tool chain of the depending action. Don't need 'Ty' in the name of this struct. ===

Re: [PATCH] D21856: [Driver][OpenMP] Add support to create jobs for bundling actions.

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D21856 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

Re: [PATCH] D21857: [Driver][OpenMP] Add support to create jobs for unbundling actions.

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D21857 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

Re: [PATCH] D21853: [Driver][OpenMP] Update actions builder to create unbundling action when necessary.

hfinkel added inline comments. Comment at: lib/Driver/Driver.cpp:2091 @@ +2090,3 @@ +InputArg->getOption().getKind() == llvm::opt::Option::InputClass && +!types::isSrcFile(HostAction->getType())) { + auto UnbundlingHostAction = hfinkel wrote:

Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

> and maybe we can find a way to rather use fpcmp/set an > absolution/relative tollerance for when comparing the results > (though admittedly I don't see how we can do that in a case of > oggenc where a .ogg file is produced). > > > - Matthias > > > > >

[PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

hfinkel added a comment. In https://reviews.llvm.org/D18639#545697, @EricWF wrote: > LGTM. > > In https://reviews.llvm.org/D18639#514991, @hfinkel wrote: > > > In https://reviews.llvm.org/D18639#491232, @mclow.lists wrote: > > > > > And is there any reason why `__libcpp_isinf` can't just return `

[libcxx] r283051 - Use __builtin_isnan/isinf/isfinite in complex

Author: hfinkel Date: Sat Oct 1 15:38:31 2016 New Revision: 283051 URL: http://llvm.org/viewvc/llvm-project?rev=283051&view=rev Log: Use __builtin_isnan/isinf/isfinite in complex The libc-provided isnan/isinf/isfinite macro implementations are specifically designed to function correctly, even in

[PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

This revision was automatically updated to reflect the committed changes. Closed by commit rL283051: Use __builtin_isnan/isinf/isfinite in complex (authored by hfinkel). Changed prior to commit: https://reviews.llvm.org/D18639?vs=67992&id=73202#toc Repository: rL LLVM https://reviews.llvm.o

[libcxx] r283052 - Remove some additional unnecessary std:: in cmath

Author: hfinkel Date: Sat Oct 1 15:38:44 2016 New Revision: 283052 URL: http://llvm.org/viewvc/llvm-project?rev=283052&view=rev Log: Remove some additional unnecessary std:: in cmath Unlike in math.h, as Eric pointed out in the review of D18639, we don't need the std:: in cmath. Modified: l

r283061 - [PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float

Author: hfinkel Date: Sat Oct 1 21:10:45 2016 New Revision: 283061 URL: http://llvm.org/viewvc/llvm-project?rev=283061&view=rev Log: [PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float Enable soft-float support on PPC64, as the backend now supports it. Also, the backend now use

[PATCH] D24907: NFC: separate file for fp denormal regression tests

hfinkel accepted this revision. hfinkel added a reviewer: hfinkel. hfinkel added a comment. This revision is now accepted and ready to land. This LGTM, although I find "fast-math.c" much easier to read than "denormalfpmode.c". How about naming it "denormal-fp-math.c" to match the option name?

[PATCH] D24909: fix for not copying fp denormal and trapping options.

hfinkel added a comment. I'm fine with setting these for consistency, but I don't understand why our failure to do this would cause problems. If you look in lib/CodeGen/CGCall.cpp and you'll see: if (!CodeGenOpts.FPDenormalMode.empty()) FuncAttrs.addAttribute("denormal-fp-math",

[PATCH] D24909: fix for not copying fp denormal and trapping options.

hfinkel added a comment. In https://reviews.llvm.org/D24909#559110, @SjoerdMeijer wrote: > Hi Hal, > Thanks for reviewing and you're right: this should work. We actually have > actually some downstream (aarch64) build attribute selection code that would > work better with this change. Are you

Re: r283141 - [analyzer] A blind attempt to fix a buildbot after r283092.

- Original Message - > From: "Artem Dergachev via cfe-commits" > To: cfe-commits@lists.llvm.org > Sent: Monday, October 3, 2016 3:12:13 PM > Subject: r283141 - [analyzer] A blind attempt to fix a buildbot after r283092. > > Author: dergachev > Date: Mon Oct 3 15:12:12 2016 > New Revision

Re: r283141 - [analyzer] A blind attempt to fix a buildbot after r283092.

- Original Message - > From: "Artem Dergachev" > To: "Hal Finkel" , "Artem Dergachev" > > Cc: cfe-commits@lists.llvm.org > Sent: Monday, October 3, 2016 3:40:02 PM > Subject: Re: r283141 - [analyzer] A blind attempt to fix a buildbot after > r283092. > > 03/10/2016 23:29, Hal Finkel пи

[PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

hfinkel added inline comments. > rjmccall wrote in CGStmt.cpp:525 > It's much more likely that NoAliasScopes will be empty than that MemoryInsts > will be empty. You should probably fast-path using that, or better yet, with > the RecordMemoryInsts bit. I'm not sure that's true; we only record

[PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

hfinkel updated this revision to Diff 73344. hfinkel added a comment. Rebased; added more comments and addressed other review feedback. https://reviews.llvm.org/D9403 Files: lib/CodeGen/CGDecl.cpp lib/CodeGen/CGExpr.cpp lib/CodeGen/CGStmt.cpp lib/CodeGen/CodeGenFunction.cpp lib/CodeGe

[PATCH] D22189: llvm.noalias - Clang CodeGen - check restrict variable map only for restrict-qualified lvalues

hfinkel updated this revision to Diff 73345. hfinkel added a comment. Rebased https://reviews.llvm.org/D22189 Files: lib/CodeGen/CGDeclCXX.cpp lib/CodeGen/CGExpr.cpp lib/CodeGen/CGOpenMPRuntime.cpp lib/CodeGen/CGStmtOpenMP.cpp lib/CodeGen/CodeGenFunction.h Index: lib/CodeGen/CodeGen

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel created this revision. hfinkel added reviewers: anemet, rsmith, rjmccall. hfinkel added a subscriber: cfe-commits. Herald added a subscriber: mcrosier. The backend now has the capability to save information from optimizations, the same information that can be used to generate optimization

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel added a dependency: D25224: Don't filter diagnostics written as YAML to the output file. hfinkel added a comment. Note: This depends on https://reviews.llvm.org/D25224. https://reviews.llvm.org/D25225 ___ cfe-commits mailing list cfe-commit

[PATCH] D19678: Annotated-source optimization reports (a.k.a. "listing" files)

hfinkel abandoned this revision. hfinkel added a comment. Abandoned in favor of https://reviews.llvm.org/D25225/https://reviews.llvm.org/D25262. https://reviews.llvm.org/D19678 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.ll

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel added a comment. @rsmith @rjmccall - I chatted with @anemet about this on IRC, and he's happy with it. Please look this over, in part to make sure you're happy with the option name. On the name, two of my thoughts behind using -fsave-optimization-record were: 1) I did not want to call

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel updated this revision to Diff 73874. hfinkel added a comment. Herald added a subscriber: fhahn. I reworked the way that the automatic file-name selection works so that it will work with offloading (e.g. CUDA), and added more tests for the automatic file-name selection. It now also bases

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel added inline comments. Comment at: lib/CodeGen/CodeGenAction.cpp:198 + +Ctx.setDiagnosticsOutputFile(new yaml::Output(OptRecordFile->os())); + } anemet wrote: > Sorry, one more thing: if PGO is available, I think we want to set > Ctx.setDiag

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel updated this revision to Diff 74001. hfinkel added a comment. Herald added a subscriber: mehdi_amini. Addressed review comments (DebugLoc is tested, and we enable hotness computation when saving the optimization record and also using PGO). https://reviews.llvm.org/D25225 Files: inclu

[PATCH] D25387: When optimizing for size, enable loop rerolling by default.

hfinkel created this revision. hfinkel added a reviewer: jmolloy. hfinkel added a subscriber: cfe-commits. Herald added a subscriber: mcrosier. We have a loop-rerolling optimization which can be enabled by using -freroll-loops. While sometimes loops are hand-unrolled for performance reasons, whe

Re: r283680 - [CUDA] Support and std::min/max on the device.

Hi Justin, This is neat! I see a bunch of uses of std::isinf, etc. here. It tends to be important that, when using -ffast-math (or -ffinite-math-only) these checks get optimized away. Can you please check that they do? If not, you might mirror what I've done in r283051 for libc++, which is sim

Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

Hi Michal, All of the libc++ and libc++abi regression tests are now failing on my Linux build system with this error: /usr/bin/ld: cannot find -lcxxabi_shared My build directory has only these: lib/libc++.a lib/libc++abi.so lib/libc++abi.so.1 lib/libc++abi.so.1.0 lib/libc++experimental.a lib

Re: r283680 - [CUDA] Support and std::min/max on the device.

- Original Message - > From: "Justin Lebar" > To: "Hal Finkel" > Cc: "Clang Commits" > Sent: Saturday, October 8, 2016 6:16:12 PM > Subject: Re: r283680 - [CUDA] Support and std::min/max on the > device. > > Hal, > > On NVPTX, these functions eventually get resolved to function calls

Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

- Original Message - > From: "Hal Finkel via cfe-commits" > To: "Michal Gorny" > Cc: cfe-commits@lists.llvm.org > Sent: Saturday, October 8, 2016 6:37:50 PM > Subject: Re: [libcxx] r283659 - [cmake] Split linked libraries into private & >

Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

> public, for linker script > > - Original Message - > > From: "Hal Finkel via cfe-commits" > > To: "Michal Gorny" > > Cc: cfe-commits@lists.llvm.org > > Sent: Saturday, October 8, 2016 6:37:50 PM > > Subject: Re: [libc

[libcxx] r283684 - [CMake] Fix in-tree libcxxabi build support after r283659

Author: hfinkel Date: Sat Oct 8 21:49:31 2016 New Revision: 283684 URL: http://llvm.org/viewvc/llvm-project?rev=283684&view=rev Log: [CMake] Fix in-tree libcxxabi build support after r283659 r283659 changed the argument to gen_link_script.py from SCRIPT_ABI_LIBNAME to LIBCXX_LIBRARIES_PUBLIC, as

Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

r283659 - [cmake] Split linked libraries into > > private & public, for linker script > > > > - Original Message - > > > From: "Hal Finkel via cfe-commits" > > > To: "Michal Gorny" > > > Cc: cfe-commits@lists.llvm.org

r283685 - When optimizing for size, enable loop rerolling by default

Author: hfinkel Date: Sat Oct 8 22:06:31 2016 New Revision: 283685 URL: http://llvm.org/viewvc/llvm-project?rev=283685&view=rev Log: When optimizing for size, enable loop rerolling by default We have a loop-rerolling optimization which can be enabled by using -freroll-loops. While sometimes loop

[PATCH] D25387: When optimizing for size, enable loop rerolling by default.

hfinkel closed this revision. hfinkel added a comment. r283685 https://reviews.llvm.org/D25387 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D25308: [Sema] Ignore transparent_union attributes in C++

hfinkel added a comment. In https://reviews.llvm.org/D25308#566176, @arphaman wrote: > The updated patch now makes clang warn every time it encounters this > attribute in C++ mode. Would that be the desired behaviour? As I understand it, transparent_union was designed for use in system headers

Re: [PATCH] D25308: [Sema] Ignore transparent_union attributes in C++

Monday, October 10, 2016 2:16:13 PM > Subject: Re: [PATCH] D25308: [Sema] Ignore transparent_union > attributes in C++ > On Mon, Oct 10, 2016 at 10:45 AM, Hal Finkel via cfe-commits < > cfe-commits@lists.llvm.org > wrote: > > hfinkel added a comment. > > > In https:

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

hfinkel added a comment. In https://reviews.llvm.org/D25225#566854, @rsmith wrote: > As discussed on IRC, I have a mild concern about using > `-fsave-optimization-record` (with no argument) to enable the feature, and > `-fsave-optimization-record=X` to enable the feature and specify a filename;

r283834 - Add an option to save the backend-produced YAML optimization record to a file

Author: hfinkel Date: Mon Oct 10 19:26:09 2016 New Revision: 283834 URL: http://llvm.org/viewvc/llvm-project?rev=283834&view=rev Log: Add an option to save the backend-produced YAML optimization record to a file The backend now has the capability to save information from optimizations, the same i

r283839 - Fixup test/Driver/opt-record.c for nvptx pointer size

Author: hfinkel Date: Mon Oct 10 20:05:45 2016 New Revision: 283839 URL: http://llvm.org/viewvc/llvm-project?rev=283839&view=rev Log: Fixup test/Driver/opt-record.c for nvptx pointer size On some systems, it looks like nvptx is used instead of nvptx64. Modified: cfe/trunk/test/Driver/opt-rec

[PATCH] D25403: [CUDA] Mark __libcpp_{isnan, isinf, isfinite} as constexpr.

hfinkel added a comment. In https://reviews.llvm.org/D25403#565603, @jlebar wrote: > Although these pass the CUDA test-suite tests (which I haven't yet committed > because they're broken without this change), I could use some help running > the libcxx tests. > > I cannot find any documentation

Re: r283680 - [CUDA] Support and std::min/max on the device.

- Original Message - > From: "Justin Lebar" > To: "Hal Finkel" > Cc: "Clang Commits" > Sent: Saturday, October 8, 2016 10:56:37 PM > Subject: Re: r283680 - [CUDA] Support and std::min/max on the > device. > > > > The fix is not as simple as simply changing our implementation of > > e.

[PATCH] D25225: Add an option to save the backend-produced YAML optimization record to a file

This revision was automatically updated to reflect the committed changes. Closed by commit rL283834: Add an option to save the backend-produced YAML optimization record to a file (authored by hfinkel). Changed prior to commit: https://reviews.llvm.org/D25225?vs=74001&id=74214#toc Repository:

Re: r283685 - When optimizing for size, enable loop rerolling by default

ailing. > Tailing the output of the program gets: > … > test 236 failed > test 236 failed > test 236 failed > test 236 failed > test 236 failed > test 236 failed > test 236 failed > On October 8, 2016 at 8:15:40 PM, Hal Finkel via cfe-commits ( > cfe-commits@lists.llv

[PATCH] D25491: [libcxx] Use C++14 when building libc++ with musl

hfinkel added inline comments. Comment at: CMakeLists.txt:327 # Required flags == set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build dialect") add_compile_flags_if_supported(-std=${LIBCXX_S

[PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

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

[PATCH] D25491: [libcxx] Use C++14 when building libc++ with musl

hfinkel added a comment. In https://reviews.llvm.org/D25491#571003, @phosek wrote: > Ping, do you have any other comments? Fine by me. Please wait for an okay by @EricWF . Repository: rL LLVM https://reviews.llvm.org/D25491 ___ cfe-commits mai

r319629 - Revert "[CodeGen] Add initial support for union members in TBAA"

Author: hfinkel Date: Sat Dec 2 19:10:13 2017 New Revision: 319629 URL: http://llvm.org/viewvc/llvm-project?rev=319629&view=rev Log: Revert "[CodeGen] Add initial support for union members in TBAA" This reverts commit r319413. See PR35503. We can't use "union member" as the access type here lik

Re: [PATCH] D24933: Enable configuration files in clang

On 07/24/2017 10:18 AM, Serge Pavlov wrote: I am thinking about reducing the patch further to leave only the ability to include config file when clang is called as `target-clang-drivermode`. It is still useful for cross compilation tasks because: - It is a convenient way to switch between sup

Re: [PATCH] D24933: Enable configuration files in clang

On 08/06/2017 01:15 PM, Serge Pavlov wrote: 2017-08-06 6:43 GMT+07:00 Hal Finkel >: On 07/24/2017 10:18 AM, Serge Pavlov wrote: I am thinking about reducing the patch further to leave only the ability to include config file when clang is called as `targ

r311041 - Base optimization-record file names on the final output

Author: hfinkel Date: Wed Aug 16 14:34:27 2017 New Revision: 311041 URL: http://llvm.org/viewvc/llvm-project?rev=311041&view=rev Log: Base optimization-record file names on the final output Using Output.getFilename() to construct the file name used for optimization recording in Clang::ConstructJo

r311043 - Don't use -no-integrated-as in test/Driver/opt-record.c

Author: hfinkel Date: Wed Aug 16 14:51:31 2017 New Revision: 311043 URL: http://llvm.org/viewvc/llvm-project?rev=311043&view=rev Log: Don't use -no-integrated-as in test/Driver/opt-record.c -no-integrated-as is not supported on some targets (e.g., x86_64-pc-windows-msvc). Testing using -save-temp

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

On 08/22/2017 09:18 PM, Xinliang David Li via llvm-commits wrote: On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits mailto:llvm-comm...@lists.llvm.org>> wrote: On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits mailto:cfe-commits@lists.llvm.org>>

r289752 - Include SmallSet.h in BackendUtil.cpp

Author: hfinkel Date: Wed Dec 14 20:19:17 2016 New Revision: 289752 URL: http://llvm.org/viewvc/llvm-project?rev=289752&view=rev Log: Include SmallSet.h in BackendUtil.cpp BackendUtil.cpp uses llvm::SmallSet but did not include the header. It was included indirectly, but this will change once the

Re: r291123 - CodeGen: plumb header search down to the IAS

On 01/05/2017 08:30 PM, Eric Christopher via cfe-commits wrote: Ok, thanks. I agree that it's a problem. I'm definitely open for testing ideas here. There are a few other things in the TargetOptions/MCTargetOptions area that are already problematic to test. I think that we need to add seriali

Re: [PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

hfinkel added inline comments. Comment at: lib/CodeGen/CGStmt.cpp:537 @@ +536,3 @@ + llvm::LLVMContext::MD_noalias), + NewScopeList)); + rjmccall wrote: > This is a very strange representati

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

hfinkel added a comment. In https://reviews.llvm.org/D18639#515000, @hfinkel wrote: > Updated to use scheme suggested by Marshall. Ping. https://reviews.llvm.org/D18639 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org

r280041 - [PowerPC] Add support for -mlongcall

Author: hfinkel Date: Mon Aug 29 20:07:03 2016 New Revision: 280041 URL: http://llvm.org/viewvc/llvm-project?rev=280041&view=rev Log: [PowerPC] Add support for -mlongcall Add support for GCC's PowerPC -mlongcall option; the backend supports the corresponding target feature as of r280040. Fixes P

r280053 - [PowerPC] Update the DWARF register-size table

Author: hfinkel Date: Mon Aug 29 21:38:34 2016 New Revision: 280053 URL: http://llvm.org/viewvc/llvm-project?rev=280053&view=rev Log: [PowerPC] Update the DWARF register-size table The PPC64 DWARF register-size table did not match the ABI specification (or GCC, for that matter). Fix that, and add

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

hfinkel added a comment. In https://reviews.llvm.org/D18639#527285, @hfinkel wrote: > In https://reviews.llvm.org/D18639#515000, @hfinkel wrote: > > > Updated to use scheme suggested by Marshall. > > > Ping. Ping. https://reviews.llvm.org/D18639

Re: r253269 - Make FP_CONTRACT ON the default.

x27;re hitting an assert at > lib/CodeGen/CGExprScalar.cpp:2570 in llvm::Value > *tryEmitFMulAdd(const (anonymous namespace)::BinOpInfo &, const > clang::CodeGen::CodeGenFunction &, clang::CodeGen::CGBuilderTy &, > bool): LHSBinOp->getNumUses( > ) == 0 && "

Re: [PATCH] D18639: Use __builtin_isnan/isinf/isfinite in complex

hfinkel added a comment. In https://reviews.llvm.org/D18639#533807, @hfinkel wrote: > In https://reviews.llvm.org/D18639#527285, @hfinkel wrote: > > > In https://reviews.llvm.org/D18639#515000, @hfinkel wrote: > > > > > Updated to use scheme suggested by Marshall. > > > > > > Ping. > > > Ping.

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

On 03/16/2017 07:40 PM, Eric Christopher wrote: On Thu, Mar 16, 2017 at 5:37 PM Hal Finkel via Phabricator mailto:revi...@reviews.llvm.org>> wrote: hfinkel added a comment. In https://reviews.llvm.org/D30415#703398, @echristo wrote: > Different suggestion: > > Remove t

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

On 03/16/2017 08:11 PM, Eric Christopher wrote: On Thu, Mar 16, 2017 at 5:45 PM Hal Finkel > wrote: On 03/16/2017 07:40 PM, Eric Christopher wrote: On Thu, Mar 16, 2017 at 5:37 PM Hal Finkel via Phabricator mailto:revi...@reviews.llvm.org>> wrote:

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

On 03/21/2017 12:19 PM, Ulrich Weigand via Phabricator wrote: uweigand added a comment. In https://reviews.llvm.org/D30415#705889, @echristo wrote: In https://reviews.llvm.org/D30415#705196, @uweigand wrote: Well, mainline GCC doesn't have -faltivec at all and never had, I think this was o

Re: [libcxxabi] r296940 - Fix PR25874 - Detect features required for cxa_thread_atexit_test.pass.cpp

Hi Eric, This does not seem to do the right thing because, at this point, we have a fall-back implementation of __cxa_thread_atexit_impl (in src/cxa_thread_atexit.cpp), and this will be compiled if libc does not provide an implementation. Thus, the test will always pass (unless LIBCXXABI_ENAB

Re: [cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Dr

On 02/08/2017 07:21 PM, Chandler Carruth wrote: It's blast from the past time! On Tue, Sep 18, 2012 at 3:28 PM Hal Finkel > wrote: Author: hfinkel Date: Tue Sep 18 17:25:07 2012 New Revision: 164177 URL: http://llvm.org/viewvc/llvm-project?rev=164177&v

Re: [cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Dr

On 02/09/2017 04:58 PM, Chandler Carruth wrote: On Thu, Feb 9, 2017 at 2:46 PM Tobias von Koch mailto:tobias.von.k...@gmail.com>> wrote: On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth mailto:chandl...@gmail.com>> wrote: +// The Freescale PPC SDK has the gcc librarie

Re: [PATCH v3] [PPC64]: Add support for Swift calling convention

On 07/19/2017 10:26 AM, Adrian Prantl wrote: On Jun 21, 2017, at 11:32 PM, Andrew Jeffery wrote: For the tests I've extracted the int5 and int8 cases to cater for different alignments for different platform ABIs. For Linux on POWER the 5 and 8 element vectors must be naturally aligned with res

Re: [PATCH] Warning for main returning a bool.

- Original Message - > From: "Aaron Ballman via cfe-commits" > To: "Joshua Hurwitz" > Cc: "cfe-commits" > Sent: Tuesday, November 15, 2016 12:17:28 PM > Subject: Re: [PATCH] Warning for main returning a bool. > > On Fri, Oct 14, 2016 at 1:17 PM, Joshua Hurwitz via cfe-commits > wrote:

  1   2   3   >