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) ;
rjmcc...@gmail.com
Cc: cfe-commits@lists.llvm.org
Subject: Re:
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 2018
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 - CodeGen: Fix address space of indirect function argument
On Mar 9, 2
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;
zj
[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] b670ab
[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: R
[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: cfe-commits@lists.
[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; cfe-commits
[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; a.bat...@hotm
[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; mlek...@s
[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; a.ba
[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;
[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) ; t...@google.com;
[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; t...@go
[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; rjmcc.
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) ; rjmcc.
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) ; rjmcc...@gmail.com; Arse
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 resolve conflicts in
include/clang/Basic/OpenCLOptio
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
On Fri, Mar 24, 2
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
I think if there is no triple environment or if the triple environment is
"opencl", I should always map default address space to 0. Then it should not
break libclc and previous OpenCL applications.
Sam
-Original Message-
From: Tom Stellard via Phabricator [mailto:revi...@reviews.llvm.or
+ 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 trans
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()
Hi Richard/Anastasia,
I agree some tests are redundant. I will try to remove them.
Thanks.
Sam
From: Anastasia Stulova [mailto:anastasia.stul...@arm.com]
Sent: Friday, November 04, 2016 7:43 AM
To: Richard Smith ; Liu, Yaxun (Sam)
Cc: nd ; cfe-commits@lists.llvm.org
Subject: RE: r273191 - [Ope
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: Th
The LLVM IR generated by Clang trunk for spir target is not conformant to SPIR
spec 1.2 or 2.0 even without my change. For example, it differs from SPIR spec
about LLVM version, image type name, sampler type representation, blocks
representation, etc. It is the result of evolution of the origina
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 ;
xiuli...@outlook.com; cfe
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 - [OpenCL] Add suppor
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: r269431 - [OpenCL] Add sup
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.
Sa
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
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) ;
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 macros.
This is because OpenCL se
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 ;
cfe-commits
Subject: R
+ 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
Subject: Re: [PATCH] D20681: Add target-specific
+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 w
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 exte
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 encourage
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 = data.ge
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 you
$ "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
'C:\cygwin64\home\ismail\src\llvm\dist\tools\clang
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
Subject: Re: r273191 - [OpenCL] Include opencl-
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: Wed
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;
anastasia.stul...@
We will take a look. Thanks.
Sam
-Original Message-
From: Benjamin Kramer [mailto:benny@gmail.com]
Sent: Thursday, June 30, 2016 5:27 AM
To: Liu, Yaxun (Sam) ; Shi, Aaron (en ye)
; anastasia.stul...@arm.com
Cc: cfe-commits
Subject: Re: r274150 - [OpenCL] Allow -cl-std and other sta
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;
alexey.ba...@intel.com; xiuli...@o
+ 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
47 matches
Mail list logo
