https://github.com/AlexVlx updated
https://github.com/llvm/llvm-project/pull/110182
>From af1adfafaa09bc7992cf9aaf34a6121cf2d56d5b Mon Sep 17 00:00:00 2001
From: Alex Voicu
Date: Thu, 26 Sep 2024 04:16:52 +0100
Subject: [PATCH 1/2] Mark globals as `constant` if they have been annotated
with `_
AlexVlx wrote:
@yxsamliu beat me to it. The problem here is that the example illustrates
language level const on a variable with internal linkage (which is mandatory
for `__constant__` variables in non-RDC compilation AFAICT from 17.5.24.1) and
we don't set externally_initialized on that, whic
Artem-B wrote:
> In this case, _ZL4cxxx does not have externally_initialized . If this patch
> does not remove externally_initialized, probably this constant propagation
> won't happen.
Indeed, unoptimized code shows that `cxxx` has no `externally_initialized`,
only `constant`.
If we keep e
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AlexVlx edited
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
yxsamliu wrote:
> It has nothing to do with writing to those arrays while the kernel is
> running. That would indeed be UB.
>
> > both would still work just the same even with this change,
>
> No, they will not. Here's the demonstration of the behavior change that
> `const` brings to the tabl
arsenm wrote:
If it's not legal for it to be marked as constant, it's also not legal to use
constant address space
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/
Artem-B wrote:
It has nothing to do with writing to those arrays while the kernel is running.
That would indeed be UB.
> both would still work just the same even with this change,
No, they will not. Here's the demonstration of the behavior change that `const`
brings to the table:
https://cuda
AlexVlx wrote:
> Well, it's certainly used that way in existing CUDA code and it's been around
> forever: Here are few random examples:
>
> * from both 10 years ago:
>
> https://stackoverflow.com/questions/20535683/cuda-5-5-cudamemcpytosymbol-constant-and-out-of-scope-error
> * fairly recent
Artem-B wrote:
Well, it's certainly used that way in existing CUDA code and it's been around
forever:
Here are few random examples from both 10 years ago:
https://stackoverflow.com/questions/20535683/cuda-5-5-cudamemcpytosymbol-constant-and-out-of-scope-error
and a fairly recent example:
https
Artem-B wrote:
I'm not 100% sure that `externally_initialized` is sufficient to deal with this
use pattern.
IR manual says: https://llvm.org/docs/LangRef.html#global-variables
> By default, global initializers are optimized by assuming that global
> variables defined within the module are not
AlexVlx wrote:
> `__constant__` may not necessarily be `const` for IR purposes. I.e. IR may
> not rely on the 'known' values, as seen in IR, as the data may actually be
> populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the GPU
> kernel launch.
But since this is marked `ex
AlexVlx wrote:
> > `__constant__` may not necessarily be `const` for IR purposes. I.e. IR may
> > not rely on the 'known' values, as seen in IR, as the data may actually be
> > populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the
> > GPU kernel launch.
>
> But since this i
Artem-B wrote:
`__constant__` may not necessarily be `const` for IR purposes. I.e. IR may not
rely on the 'known' values, as seen in IR, as the data may actually be
populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the GPU
kernel launch.
https://github.com/llvm/llvm-project
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Alex Voicu (AlexVlx)
Changes
Currently, `__constant__` variables do not get unconditionally marked as
`constant` in IR, which seems a bit odd given their definition. This is
generally inconsequential for NVPTX/AMDGPU, since said variables
llvmbot wrote:
@llvm/pr-subscribers-clang-codegen
Author: Alex Voicu (AlexVlx)
Changes
Currently, `__constant__` variables do not get unconditionally marked as
`constant` in IR, which seems a bit odd given their definition. This is
generally inconsequential for NVPTX/AMDGPU, since said v
llvmbot wrote:
@llvm/pr-subscribers-backend-amdgpu
Author: Alex Voicu (AlexVlx)
Changes
Currently, `__constant__` variables do not get unconditionally marked as
`constant` in IR, which seems a bit odd given their definition. This is
generally inconsequential for NVPTX/AMDGPU, since said
https://github.com/AlexVlx created
https://github.com/llvm/llvm-project/pull/110182
Currently, `__constant__` variables do not get unconditionally marked as
`constant` in IR, which seems a bit odd given their definition. This is
generally inconsequential for NVPTX/AMDGPU, since said variables
18 matches
Mail list logo
