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 ]

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,

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

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=rev Log: Fix for PR32990 This fixes the bug in https://bugs.llvm.org/show_bug.cgi?id=32990. Too late now, but

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=rev Log: [VerifyDiagnosticConsumer] support -verify= This mimics FileCheck's --check-prefixes option. The default prefix is "expected". That is, "-verify" is equivalent to

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=rev Log: [TextDiagnosticBuffer] Fix diagnostic note emission order The frontend currently groups diagnostics from the command line according to diagnostic level, but that

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=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 like

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

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

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

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

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

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: [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 > wrote: Nevertheless, I think that you've convinced me that this is a least-bad solution. I'll want a flag

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

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

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

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

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

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=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 element

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

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 > wrote: On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits

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=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-temps is

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=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::ConstructJob,

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

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

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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On 05/01/2017 02:35 PM, Krzysztof Parzyszek via cfe-commits wrote: On 5/1/2017 2:16 PM, Hal Finkel via cfe-commits wrote: On 05/01/2017 12:49 PM, Daniel Berlin wrote: On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote: ... Our struct-path TBAA does the following: struct X

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On 05/01/2017 02:31 PM, Daniel Berlin wrote: So you believe that you can index into an object randomly by pointer arithmetic and pull out a different field? For starters, this is illegal because you don't know where the padding bytes are. You cannot assume that X.a + 1

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

On 05/01/2017 12:49 PM, Daniel Berlin wrote: On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator > wrote: hfinkel added a comment. In https://reviews.llvm.org/D32199#732737

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

Richard, et al., Any feedback on my comments below on what C/C++ allows? I'd like to just be missing something ;) Thanks again, Hal On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote: ... Our struct-path TBAA does the following: struct X { int a, b; }; X x { 50, 100 }; X

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

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

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

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 > wrote: hfinkel added a comment. In https://reviews.llvm.org/D30415#703398, @echristo wrote: > Different

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 > wrote: On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth > wrote:

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:

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=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: [libcxx] r288544 - Work around a bug in Clang's implementation of noexcept function types

- Original Message - > From: "Eric Fiselier via cfe-commits" > To: cfe-commits@lists.llvm.org > Sent: Friday, December 2, 2016 4:30:53 PM > Subject: [libcxx] r288544 - Work around a bug in Clang's implementation of > noexcept function types > > Author: ericwf

Re: r288448 - [CUDA] "Support" ASAN arguments in CudaToolChain

- Original Message - > From: "Jason Henline via cfe-commits" > To: cfe-commits@lists.llvm.org > Sent: Thursday, December 1, 2016 7:42:54 PM > Subject: r288448 - [CUDA] "Support" ASAN arguments in CudaToolChain > > Author: jhen > Date: Thu Dec 1 19:42:54 2016

r287999 - Adjust type-trait evaluation to properly handle Using(Shadow)Decls

Author: hfinkel Date: Sun Nov 27 10:26:14 2016 New Revision: 287999 URL: http://llvm.org/viewvc/llvm-project?rev=287999=rev Log: Adjust type-trait evaluation to properly handle Using(Shadow)Decls Since r274049, for an inheriting constructor declaration, the name of the using declaration (and

[PATCH] D24933: Enable configuration files in clang

hfinkel added a comment. What happens with unused arguments in the configuration files? This feature looks potentially useful for me, but only if it suppresses unused-argument warnings. For example, if I put -L/usr/local/lib -stdlib=libc++ into a configuration file, I can't have these:

[PATCH] D26807: Fix a comment for -fsave-optimization-record

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

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

- Original Message - > From: "Aaron Ballman" > To: "Hal Finkel" > Cc: "cfe-commits" , "Joshua Hurwitz" > > Sent: Tuesday, November 15, 2016 4:42:05 PM > Subject: Re: [PATCH] Warning for main

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. >

[PATCH] D26564: Use PIC relocation mode by default for PowerPC64 ELF

hfinkel added a comment. @wschmidt and other IBM folks, w.r.t. this and https://reviews.llvm.org/D26566, can you please comment on what GCC does here? Does GCC use -fPIC by default for PPC64 (literally or in effect)? https://reviews.llvm.org/D26564

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

hfinkel added a comment. In https://reviews.llvm.org/D25403#590049, @jlebar wrote: > Use TEST_STD_VER macro. This is fine with me; @EricWF , @mclow.lists ? https://reviews.llvm.org/D25403 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

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

hfinkel added inline comments. Comment at: libcxx/test/libcxx/numerics/c.math/constexpr-fns.pass.cpp:24 + +#if __cplusplus >= 201103L +constexpr bool a = std::__libcpp_isnan(0.); I think the preferred form here is: #if TEST_STD_VER >= 11

[PATCH] D25764: Add end location of loop to loop metadata.

hfinkel added a comment. This makes sense to me; @anemet , @rjmccall , any thoughts? https://reviews.llvm.org/D25764 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D14274: Add alloc_size attribute to clang

hfinkel added a comment. What's the status of this? https://reviews.llvm.org/D14274 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[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#584010, @twoh wrote: > Is there a particular reason why "opt_record_file" is defined in > CC1Options.td, not Options.td? If -opt-record-file= is provided by > the command line, line 829-831 in CompilerInvocation.cpp won't handle it >

Re: r285544 - Add support for __builtin_alloca_with_align

Hi David, On Reid's patch for this (D25581), Richard said, "This takes the alignment in bits? That's so ridiculously dumb that I would feel bad about accepting this patch unless it comes with a warning for people writing the obvious-but-wrong __builtin_alloca_with_align(sizeof(T),

Re: r284256 - Link static PIE programs against rcrt0.o on OpenBSD

- Original Message - > From: "Brad Smith via cfe-commits" > To: "Ed Maste" , sisnk...@gmail.com, > cfe-commits@lists.llvm.org > Sent: Sunday, October 30, 2016 12:57:44 AM > Subject: Re: r284256 - Link static PIE programs against rcrt0.o on

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

hfinkel added a comment. In https://reviews.llvm.org/D25403#580444, @jlebar wrote: > //Let "CE" mean "constexpr-evaluatable". // > > libc++ attempts to be backwards-compatible with old versions of clang, right? Yea, we'd need to ifdef the test for older versions of Clang. I've just summarized

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

hfinkel added a comment. In https://reviews.llvm.org/D25403#580439, @jlebar wrote: > > I'm not sure about that. It seems like a useful feature for the builtins to > > have. Logically speaking, they should be constexpr. > > I agree that it's logically correct for the builtins to be >

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

hfinkel added a comment. In https://reviews.llvm.org/D25403#580432, @jlebar wrote: > In https://reviews.llvm.org/D25403#580422, @hfinkel wrote: > > > Okay. Why not fix the Clang builtins so that they're evaluatable for > > constant inputs in a constexpr context? Then we can do this and test the

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

hfinkel added a comment. In https://reviews.llvm.org/D25403#580416, @jlebar wrote: > > Is this because the functions are in instead of in are > > you don't want to mark all of as host/device? > > Yes. cmath is its own beast; we need to have our own implementation of it in > order to direct

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

hfinkel added a comment. ... > > >> I guess I don't understand the motivation for this change. > > To make work in CUDA, we do the following terrible, awful, > horrible, no good thing: ...well, I can just show you the code. >

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

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM Comment at: lib/Driver/Tools.cpp:334 + LksStream << " OpenMP Offload Linker Script.\n"; + LksStream << "*/\n"; + LksStream << "TARGET(binary)\n";

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

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM Comment at: lib/Driver/Driver.cpp:2091 +InputArg->getOption().getKind() == llvm::opt::Option::InputClass && +!types::isSrcFile(HostAction->getType()))

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

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

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

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

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

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

[PATCH] D25686: [Driver] Support "hardfloat" vendor triples used by Gentoo

hfinkel added a comment. It seems like we should teach Triple how to parse this triples correctly (i.e. to recognize that the vendor is ARM), and then canonicalize the environment to GNUEABIHF (or whatever)? https://reviews.llvm.org/D25686 ___

[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

[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 inline comments. Comment at: CMakeLists.txt:327 # Required flags == set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build dialect")

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

e.Benchmarks.Adobe-C++.loop_unroll appears to be failing. > 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,

[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=74214#toc Repository:

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

[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

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=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:

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=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

[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

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

; <r...@google.com>, > "Aaron Ballman" <aaron.ball...@gmail.com>, "cfe-commits" > <cfe-commits@lists.llvm.org> > Sent: Monday, October 10, 2016 2:16:13 PM > Subject: Re: [PATCH] D25308: [Sema] Ignore transparent_union > attributes in C++ > On

[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

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=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 loops

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

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

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

- Original Message - > From: "Hal Finkel via cfe-commits" <cfe-commits@lists.llvm.org> > To: "Michal Gorny" <mgo...@gentoo.org> > Cc: cfe-commits@lists.llvm.org > Sent: Saturday, October 8, 2016 6:37:50 PM > Subject: Re: [libcxx] r28365

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

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

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

[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,

[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 >

[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

[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

[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

[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

[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:

[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

[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

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

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

[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

[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] 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?

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=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 uses

[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=73202#toc Repository: rL LLVM

[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=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:

[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=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 the

  1   2   3   >