- User Since
- Feb 5 2016, 5:41 AM (210 w, 6 d)
Jul 5 2019
FWIW I've just hit the same issue, and this patch works great for me.
Oct 6 2018
This change has caused Clang to start emitting erroneous warnings when using OpenCL's vector specifier, e.g. "%v4f", which doesn't seem to be covered by the format string analysis.
Apr 4 2017
Thanks for the review! Would you be able to commit this on my behalf?
Apr 1 2017
Mar 20 2017
Ping - maybe this got lost in the noise.
Mar 10 2017
Thanks - could you commit this on my behalf please?
Feb 24 2017
This patch is now obsolete - the core issue has now been fixed by D27283. While that fix is a little more conservative (i.e. it doesn't replace the alloca when it sometimes could), it's good enough to fix all of the issues that I was experiencing in my downstream projects, so I'm happy to leave it at that.
Thanks for the speedy review!
Feb 14 2017
Jan 31 2017
- Remove accidental debug statement
Jan 26 2017
Thanks for the feedback, responses inline.
- Address review comments from mehdi_amini
Jan 25 2017
- Handle different global and function arg address spaces properly
- Use llvm_unreachable instead of assert(false)
- Rebase to current trunk
Jan 20 2017
I don't know if it's too late, but I'd love for this to make it into the 4.0 release. Although this bug has been present for a while so perhaps isn't strictly a regression, there is a regression in downstream projects that I'm working on due to (valid) changes in the IR generated by Clang since 3.9 which expose this bug.
Jan 6 2017
- Address review comments from arsenm
Jan 4 2017
Fix memtransfer function type deduction
Sep 15 2016
Sep 14 2016
Does this also need the CUDA library to be added to streamexecutor-config output for --libs?
Sep 12 2016
I believe LLVMConfig.cmake defines an LLVM_ENABLE_RTTI variable which can give you this information directly, without the need for the execute_process().
Sep 9 2016
I've just noticed that this patch split the Utils target into a separate installed library (libutils.a), which breaks things building against SE using streamexecutor-config.
Sep 8 2016
Sep 7 2016
BTW, I don't have commit access, so I'm afraid someone else will have to commit this on my behalf.
Maybe I'm doing something wrong, but the single-quotes wrapping the include/lib paths given by --cppflags and --ldflags are not working for me. The compiler fails to find the StreamExecutor headers and libraries, and warns that the library directory doesn't exist. It's almost as if the quotes are being taken as part of the paths.
Sep 6 2016
Looks good, with one minor nit.
Sep 5 2016
Sep 2 2016
Aug 31 2016
Hmm, maybe a false alarm.
The getOrDie function seems to be generating an additional 'unchecked error' message when dying. For example, this trivial program (which should obviously generate an error):
Aug 30 2016
Aug 26 2016
Aha, this explains why I couldn't find these classes in the docs yesterday.
Aug 24 2016
Not sure what the protocol is for finding issues in patches that have already been committed - should I be posting to parallel_libs-dev instead?
Aug 23 2016
Just some mild pedantry from me.
Aug 16 2016
General question: if we have variants of these memcpy methods that take ElementCount parameters to allow for partial copies to/from the device allocations, should we also have variants with an Offset parameter as well to allow for partial copies that don't start at the origin?
Aug 12 2016
One last nit from me.
FWIW, this design feels a lot cleaner to me :-)
Aug 10 2016
I think I understand the motivation for restricting the use of StreamExecutor::launch/memcpy etc to only the Stream class via the StreamKey struct, but I'm not sure I see the need for the StreamExecutorKey struct. It seems like this is currently just protecting the Stream constructor, but is it really a problem if someone can write new Stream(Executor, nullptr) as well as Executor->createStream()? Don't have strong opinions about this, just curious.