RE: [PATCH] D141437: [HIP] Use .hipi as preprocessor output extension

[AMD Official Use Only - General] Fixed by 503e02e861662ef84940fdc05e26c12fc0fca7f3. Thanks. Sam -Original Message- From: Nico Weber via Phabricator Sent: Wednesday, January 11, 2023 11:25 PM To: Liu, Yaxun (Sam) ; t...@google.com Cc: tha...@chromium.org; mask...@google.com;

RE: [clang] 829d14e - Revert "[NFC] Refactor DiagnosticBuilder and PartialDiagnostic"

[AMD Public Use] It was reverted because it caused regressions in some CUDA apps. Is there a way for me to modify the commit message? Thanks. Sam -Original Message- From: Roman Lebedev Sent: Thursday, September 17, 2020 2:14 PM To: Liu, Yaxun (Sam) ; Yaxun Liu Cc:

RE: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] commit 2c31aa2de13a23a00ced87123b92e905f2929c7b should fix this. Thanks. Sam -Original Message- From: Liu, Yaxun (Sam) Sent: Sunday, April 5, 2020 12:20 PM To: Joerg Sonnenberger ; Yaxun Liu Cc: cfe-commits@lists.llvm.org Subject:

RE: [clang] b670ab7 - recommit 1b978ddba05c [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] The issue is addressed by https://reviews.llvm.org/D77028 Sam -Original Message- From: Joerg Sonnenberger Sent: Sunday, April 5, 2020 9:48 AM To: Liu, Yaxun (Sam) ; Yaxun Liu Cc: cfe-commits@lists.llvm.org Subject: Re: [clang]

RE: [PATCH] D76262: [NFC] Add UsedDeclVisitor

[AMD Official Use Only - Internal Distribution Only] I am taking a look. Thanks. Sam -Original Message- From: Jacques Pienaar via Phabricator Sent: Wednesday, March 18, 2020 6:14 PM To: Liu, Yaxun (Sam) ; rjmcc...@gmail.com Cc: jpien...@google.com; cfe-commits@lists.llvm.org;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] Will do. Thanks. Sam -Original Message- From: Erich Keane via Phabricator Sent: Wednesday, February 19, 2020 8:52 AM To: Liu, Yaxun (Sam) ; t...@google.com; rjmcc...@gmail.com; rich...@metafoo.co.uk; jdoerf...@anl.gov;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] Reverted. I will make sure it does not regress mlir before commit again. Thanks. Sam -Original Message- From: Eric Christopher via Phabricator Sent: Tuesday, February 18, 2020 11:21 AM To: Liu, Yaxun (Sam) ; t...@google.com;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] Probably I missed something. I will look again. Thanks. Sam -Original Message- From: Jacques Pienaar Sent: Tuesday, February 18, 2020 8:56 AM To: Liu, Yaxun (Sam) Cc: reviews+d70172+public+e13d5528b180f...@reviews.llvm.org;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] It seems to be caused by some commit hash before 20c5968e0953d978be4d9d1062801e8758c393b5. Sam -Original Message- From: Jacques Pienaar via Phabricator Sent: Monday, February 17, 2020 10:58 AM To: Liu, Yaxun (Sam) ;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] I am taking a look. Thanks. Sam -Original Message- From: Jacques Pienaar via Phabricator Sent: Monday, February 17, 2020 10:58 AM To: Liu, Yaxun (Sam) ; t...@google.com; rjmcc...@gmail.com; rich...@metafoo.co.uk; jdoerf...@anl.gov;

RE: [PATCH] D70172: [CUDA][HIP][OpenMP] Emit deferred diagnostics by a post-parsing AST travese

[AMD Official Use Only - Internal Distribution Only] Thanks a lot for fixing it. Sam -Original Message- From: Fangrui Song via Phabricator Sent: Sunday, February 16, 2020 8:41 PM To: Liu, Yaxun (Sam) ; t...@google.com; rjmcc...@gmail.com; rich...@metafoo.co.uk; jdoerf...@anl.gov;

RE: [PATCH] D62483: [CUDA][HIP] Emit dependent libs for host only

Fixed by 361905. Sam -Original Message- From: Petr Hosek via Phabricator Sent: Tuesday, May 28, 2019 9:54 PM To: Liu, Yaxun (Sam) ; t...@google.com Cc: pho...@google.com; cfe-commits@lists.llvm.org; mlek...@skidmore.edu; blitzrak...@gmail.com; shen...@google.com; jle...@google.com;

RE: r337540 - Sema: Fix explicit address space cast in C++

From: Richard Smith [mailto:rich...@metafoo.co.uk] Sent: Friday, July 20, 2018 3:29 PM To: Liu, Yaxun (Sam) Cc: cfe-commits Subject: Re: r337540 - Sema: Fix explicit address space cast in C++ On Fri, 20 Jul 2018 at 12:00, Richard Smith mailto:rich...@metafoo.co.uk>> wrote: On Fri, 20 Jul

RE: [PATCH] D44747: Set calling convention for CUDA kernel

Let's revert it for now. I will create a review after fixing it and commit it again with the fix. Thanks. Sam -Original Message- From: Artem Belevich via Phabricator [mailto:revi...@reviews.llvm.org] Sent: Tuesday, April 03, 2018 2:09 PM To: Liu, Yaxun (Sam) ;

RE: [PATCH] D44747: Set calling convention for CUDA kernel

I will try fixing that. The CUDA kernel calling convention should be dropped in all DRE's since it is invisible to the user. Sam -Original Message- From: Artem Belevich via Phabricator [mailto:revi...@reviews.llvm.org] Sent: Tuesday, April 03, 2018 1:51 PM To: Liu, Yaxun (Sam)

RE: r326946 - CodeGen: Fix address space of indirect function argument

I will try implementing John's suggestions. Thanks. Sam From: rjmcc...@apple.com [mailto:rjmcc...@apple.com] Sent: Saturday, March 10, 2018 12:14 PM To: Richard Smith Cc: Liu, Yaxun (Sam) ; cfe-commits Subject: Re: r326946

RE: [PATCH] D39069: CodeGen: Fix missing debug loc due to alloca

I will simplify the test. Thanks. Sam From: David Blaikie [mailto:dblai...@gmail.com] Sent: Monday, October 23, 2017 2:08 PM To: reviews+d39069+public+8da79e110d303...@reviews.llvm.org; Yaxun Liu via Phabricator ; Liu, Yaxun (Sam) ;

RE: r298767 - [AMDGPU] Switch address space mapping by triple environment amdgiz

Thanks for your comments. I will fix that. Sam From: Eric Christopher [mailto:echri...@gmail.com] Sent: Saturday, March 25, 2017 1:52 AM To: Liu, Yaxun (Sam) ; cfe-commits@lists.llvm.org Subject: Re: r298767 - [AMDGPU] Switch address space mapping by triple environment amdgiz

RE: PATCH: re-enable OpenCL extensions

I think the supported extensions for a target should be as accurate as possible, for it to be useful. Setting all extensions to be supported on all targets will defeat its purpose. I recommend to introduce "pocl" as an environment in the triple and add supported OpenCL extensions for different

RE: r289991 - Revert r289979 due to regressions

Thanks. Sam From: Reid Kleckner [mailto:r...@google.com] Sent: Friday, December 16, 2016 5:24 PM To: Liu, Yaxun (Sam) Cc: cfe-commits Subject: Re: r289991 - Revert r289979 due to regressions This revert broke the build because you failed to

RE: D26157: [OpenCL] always use SPIR address spaces for kernel_arg_addr_space MD

Even if we use string for address space MD, we still need to define them somewhere. On the other hand, if we use SPIR enum, we just need to refer to the SPIR spec in the documenting comments. Sam -Original Message- From: Pekka Jääskeläinen [mailto:pekka.jaaskelai...@gmail.com] Sent:

RE: [PATCH] D25343: [OpenCL] Mark group functions as convergent in opencl-c.h

Just my two cents. Let's consider a simple example: for (int I = 0; I < 2; I++) { A = Compute(); barrier(); Use(A); } This does not mean Compute() needs to be executed for all the loop iterations before barrier() being executed. This only means that during each loop iteration, Compute()

RE: [PATCH] D25343: [OpenCL] Mark group functions as convergent in opencl-c.h

+ Tom Matt Thanks Ettore. I think OpenCL is subject to the same issue, and noduplicate does not help either. Basically if a function A directly or indirectly calls a convergent function e.g. barrier, function A itself must also be marked as convergent, otherwise optimization passes may

RE: [PATCH] D21567: [OpenCL] Generate struct type for sampler_t and function call for the initializer

+ Brian Hi Anastasia, The advantage for translating sampler variable to a global variable with __sampler_initializer type is that it is consistent with OpenCL C++ and SPIRV, so it is easier to translate the IR to SPIRV. About the type name of sampler_t in LLVM, using a name without `.` allows

RE: [PATCH] D21031: [OpenCL] Allow -cl-std and other standard -cl- options in driver

We will add it. Thanks. Sam -Original Message- From: Jan Vesely [mailto:jan.ves...@rutgers.edu] Sent: Friday, July 1, 2016 4:59 PM To: Shi, Aaron (en ye) ; anastasia.stul...@arm.com Cc: jan.ves...@rutgers.edu; nhaus...@gmail.com; rich...@metafoo.co.uk;

RE: [PATCH] D19932: [OpenCL] Add to_{global|local|private} builtin functions.

The returned pointer should point to the same pointee type as the argument. Header file cannot guarantee that. Sam -Original Message- From: Jan Vesely [mailto:jan.ves...@rutgers.edu] Sent: Wednesday, June 22, 2016 10:20 PM To: Liu, Yaxun (Sam) ; xiuli...@outlook.com;

RE: r273191 - [OpenCL] Include opencl-c.h by default as a clang module

I have a patch which may workaround this issue, however I could not test it in Cygwin since I got issues build latest cmake in Cygwin and the downloaded cmake does not work. Could you please try it? Thanks. Sam -Original Message- From: Ismail Donmez [mailto:ism...@i10z.com] Sent:

RE: r273191 - [OpenCL] Include opencl-c.h by default as a clang module

The cmake of Cygwin itself does not support llvm. Which cmake did you use on Cygwin? Thanks. Sam -Original Message- From: Ismail Donmez [mailto:ism...@i10z.com] Sent: Wednesday, June 22, 2016 12:37 PM To: Liu, Yaxun (Sam) Cc: cfe-commits

RE: r273191 - [OpenCL] Include opencl-c.h by default as a clang module

$ "chmod" "u-w" "C:\cygwin64\home\ismail\src\llvm\dist\tools\clang\test\Headers\Output\opencl-c-header.cl.tmp/*" # command stderr: r.cl.tmp/*: invalid mode: 'mp/*' the error msg is strange. On my Cygwin I got different error: chmod: cannot access

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

Hi Jeroen, Thanks for your consideration. I am OK with removing those extensions which do not affect language or builtin functions. After removing them, they will be unknown to Clang. If a user tries to enable them, a warning will be emitted saying the extension is unknown. Anastasia, are

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

Sorry for the delay. In ParsePragma.cpp: void Parser::HandlePragmaOpenCLExtension() { assert(Tok.is(tok::annot_pragma_opencl_extension)); OpenCLExtData data = OpenCLExtData::getFromOpaqueValue(Tok.getAnnotationValue()); unsigned state = data.getInt(); IdentifierInfo *ename =

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

Hi Jeroen, I added all extensions since it may be useful for users to know that certain extensions are supported by a platform. The spec does not specify those options which do not affect language semantics should or should not be defined. I am considering removing them since they may

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

Hi Jeroen, OpenCL spec v1.1 s9.1 says Every extension which affects the OpenCL language semantics, syntax or adds built-in functions to the language must create a preprocessor #define that matches the extension name string. This #define would be available in the language if and only if the

RE: [PATCH] D20681: Add target-specific pre-linking passes to Clang

+Jeff To cite some of the previous discussions (http://lists.llvm.org/pipermail/cfe-dev/2016-May/048822.html ) Brian: On our side, we use such pre-link passes to interface with the specifics of our built-in function library. For example, we transform printf calls into a form that interacts

RE: [PATCH] D20681: Add target-specific pre-linking passes to Clang

+ Brian -Original Message- From: Tom Stellard [mailto:thomas.stell...@amd.com] Sent: Thursday, May 26, 2016 11:11 AM To: Liu, Yaxun (Sam) ; rich...@metafoo.co.uk; anastasia.stul...@arm.com Cc: Stellard, Thomas ; cfe-commits@lists.llvm.org

RE: [PATCH] D20630: [OpenCL] Allow -std=CL|CL1.1|CL1.2|CL2.0 in driver

I will fix that. Thanks. Sam From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith Sent: Wednesday, May 25, 2016 2:54 PM To: Liu, Yaxun (Sam) ; reviews+d20630+public+1c58d99d1f368...@reviews.llvm.org Cc: alexey.ba...@intel.com; Anastasia Stulova

RE: r267590 - [OpenCL] Add predefined macros.

I will take a look. Thanks. Sam -Original Message- From: Anastasia Stulova [mailto:anastasia.stul...@arm.com] Sent: Wednesday, May 25, 2016 10:29 AM To: Liu, Yaxun (Sam) ; cfe-commits@lists.llvm.org Cc: nd Subject: RE: r267590 - [OpenCL] Add predefined

RE: r267590 - [OpenCL] Add predefined macros.

Did clang accept -std=CL2.0 before this change? According to this diff, the only accepted option for -std= is c99 when compiling OpenCL programs. Sam -Original Message- From: Anastasia Stulova [mailto:anastasia.stul...@arm.com] Sent: Tuesday, May 24, 2016 2:48 PM To: Liu, Yaxun (Sam)

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

I think this feature can be implemented by keeping a record of enabled OpenCL extensions by user's program. For optional core feature cl_khr_fp64, we just need to detect if double type is used by user's program. Sam -Original Message- From: Liu, Yaxun (Sam) Sent: Friday, May 20, 2016

RE: r269670 - [OpenCL] Add supported OpenCL extensions to target info.

Currently Clang does not emit opencl.used.extensions metadata, so the issue mentioned does not exist. Also extensions supported by a target and extensions used by an OpenCL program is different concept. I'd say Clang currently miss a feature to detect used extensions and emit the metadata.

RE: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

BTW is there a way to turn on this warning with CMake? I could not see this warning in my own build. Thanks. Sam -Original Message- From: Liu, Yaxun (Sam) Sent: Friday, May 13, 2016 1:33 PM To: 'steve...@apple.com' Cc: cfe-commits@lists.llvm.org Subject: RE:

RE: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

Thanks Steven. I have reverted my change. I will apply your patch and re-commit. Sam -Original Message- From: steve...@apple.com [mailto:steve...@apple.com] Sent: Friday, May 13, 2016 1:27 PM To: Liu, Yaxun (Sam) Cc: cfe-commits@lists.llvm.org Subject: Re: r269431 -

RE: [PATCH] D19484: [OpenCL] Add supported OpenCL extensions to target info.

Done. Thanks for letting me know. Sam -Original Message- From: Jun Bum Lim [mailto:junb...@codeaurora.org] Sent: Friday, May 13, 2016 1:10 PM To: Liu, Yaxun (Sam) ; anastasia.stul...@arm.com; aleksey.ba...@mail.ru Cc: junb...@codeaurora.org; Stellard, Thomas