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

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

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

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

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

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

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

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

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

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

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

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 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] 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 mailto:revi...@reviews.llvm.org>> wrote: hfinkel added a comment. In https://reviews.llvm.org/D32199#732737 , @rsmith wrote: > I

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 LIBCXXABI_ENAB

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

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: [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 > Date: Fri Dec 2 16:30:52

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 > New Revision: 288448 > > U

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&view=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: cl

[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 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

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 returning a bool. > > On Tue, Nov 15, 2016 at 5:22 PM, Hal Finkel wrote: > > - Original Me

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:

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

[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 https://reviews.llvm.o

[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), alignof(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 OpenBSD > > On 10/25/16 19:34, Brad Smith via cf

[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. Here's what I suggest: 1. We commit this patch (I think it logically makes sense; the builtins should be constexpr evaluatable, even if they're currently not) 2. We follow up by fixing Clang to make the builtins constexpr evaluatable (since I think that makes sense rega

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

[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. > https://github.com/llvm-project/llvm-project/blob/master/clang/l

[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 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

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

hfinkel accepted this revision. hfinkel added a comment. This revision is now accepted and ready to land. LGTM Comment at: lib/Driver/Driver.cpp:1949 +SpecializedBuilders.push_back(new OpenMPActionBuilder(C, Args, Inputs)); + // sfantao wrote: > hfinke

[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 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

[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 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe

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

[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

[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") add_compile_flags_if_supported(-std=${LIBCXX_S

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] 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: 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] 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&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

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

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

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

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

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

[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

> 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

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

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.

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

[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

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

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 пи

  1   2   3   >