- User Since
- Jan 8 2015, 1:53 PM (262 w, 1 d)
Tank you for splitting the patch. For CMake parts @beanz would be the person to make the call.
Oops. Herald rule misfired.
Thu, Jan 16
LGTM. Added @beanz for the review of CMake file changes.
Mon, Jan 6
Fri, Dec 20
Thu, Dec 19
What's the use case for this flag?
Dec 18 2019
... I'm curious if it's particularly useful. Last time I checked NVIDIA didn't ship libcudart for FreeBSD and without it it's rather cumbersome to use CUDA in practice.
Dec 10 2019
I wonder if this patch will help with this case:
Looks good to me overall. I've pinged rsmith@ to double-check that we're covering all possibilities for non-local variable init.
Dec 9 2019
Dec 6 2019
> Command Output (stderr): > -- > /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/llvm/test/CodeGen/NVPTX/atomics-sm60.ll:6:10: error: CHECK: expected string not found in input > ; CHECK: atom.add.f64 > ^ > <stdin>:1:1: note: scanning from here > // > ^ > <stdin>:34:2: note: possible intended match here > atom.cas.b64 %rd3, [%r1], %rd2, %rd1; > ^
+1 for tests.
Dec 5 2019
Nov 18 2019
LGTM, though I'm curious if it's particularly useful. Last time I checked NVIDIA didn't ship libcudart for FreeBSD and without it it's rather cumbersome to use CUDA in practice.
You can compile a kernel, but kernel loading, launching, and related data transfers will all need to be done via driver API. It should be possible to implement a functional replacement, but I'm not aware of any existing open-source implementations. I'm also not sure if clang will be able to deal with CUDA headers correctly on FreeBSD as CUDA headers do sometimes seem to rely on implementation specifics of Linux headers.
Nov 14 2019
Nov 13 2019
Calling @rnk for Windows know-how.
Nov 7 2019
Nov 6 2019
Apologies for the delay with my response.
Nov 5 2019
Nov 4 2019
LGTM in general. Nit about test name and test scope.
Nov 1 2019
Oct 31 2019
@arsenm has a point. We can do it in clang, and it seems to be a better long-term solution compared to patching-up the inputs' AS that we've done for NVPTX and, now, AMDGPU.
Could you, please, give us a bit more context and provide more info for the questions @rjmccall and I asked before?
Oct 30 2019
Would I be too far off the mark to summarize the situation this way?
Oct 29 2019
@echristo Eric, any thoughts/concerns on the overall direction for the driver?
@rnk Reid, would you be the right person to look at the change on the Windows' side?
Oct 28 2019
The CUDA builtin library is apparently compiled in C++ mode, so the
assumption of convergent needs to be made in a typically non-SPMD
Oct 24 2019
Perhaps we should rename -fcuda-allow-variadic-functions to -fgpu-allow-variadic-functions after this patch.
Oct 23 2019
Added a comment
Oct 22 2019
Thank you for adding the warning. One small nit about the name. LGTM otherwise.
Oct 21 2019
Nice. I wish we could do that for CUDA.
Oct 18 2019
Neat. I like the visual cues showing what gets passed on to the next processing stage.
Oct 17 2019
This is... rather oddly-structured output. My brain refuses to accept that the most-indented phase is the input.
Perhaps we should do llvm::errs().indent(MaxIdent-Ident). This should give us something like this (withMaxIdent=9), which is somewhat easier to grok, IMO:
Could you give an example of before/after output?
Oct 15 2019
@rsmith Richard, could you take a look, please? Lambdas, mangling, ODR rules & ABI scare me. :-)
Oct 14 2019
Addressed Tim's comments.
Oct 11 2019
Oct 10 2019
Sometimes I wish it would be possible to specify some of the -verify diagnostics in temporal order, as opposed to tying them to locations. I.e. in this case it would be way more useful to see the call stack leading to the error at B::B. Oh, well.
Oct 9 2019
Oct 8 2019
Maybe, add a TODO to eventually remove .d .
.cui should probably remain as it's yet another variant of preprocessed output that we allow bundling for C/C++.
Added Manuel as someone familiar with tooling.
+1 to formalizing how we want -M*/-E/-S/-emit-llvm/-fsyntax-only to behave.
OK with -M/-E/-S defaulting to host, and erroring out if applied to multiple sub-compilations.
I'm still convinced that the tooling issue with multiple subcompilations is orthogonal to this change and should be handled in libclang and that -fsyntax-only should not default to one sub-compilation.
Oct 7 2019
I'm fine with this for -E/-M,
Could you elaborate on how exactly current implementation does not work?
Oct 3 2019
Oct 2 2019
LGTM. Thank you for fixing this.
Could you also add a check for -S w/o -emit-llvm, too ? AFAICT it currently wants to produce a bundle, which is not very helpful.
Oct 1 2019
Does it produce textual IR if used with -S?
The functionality looks generic enough. Should it be just flink_builtin_bitcode?