- User Since
- Jan 8 2015, 1:53 PM (298 w, 14 h)
Fixed compatibility with pre-c++11
Tue, Sep 22
Mon, Sep 21
Fri, Sep 18
Thu, Sep 17
If you dd -S and remove -ccc-print-bindingsthis command does produce a PCH.
Apparently this patch triggers compiler crashes on some of our code. I'll try to create a reproducer, but it would be great to revert the patch for now.
Wed, Sep 16
Does this naming scheme the same as used for .o files? We may want to keep them in sync.
This is a very nice cleanup. Thank you, Sam.
Tue, Sep 15
Mon, Sep 14
Can you elaborate on the use case of PCH files for CUDA/HIP?
So, the idea here is to do some sort of duck-typing and allow DiagBuilder to work with both DiagnosticBuilder and PartialDiagnostic.
Thu, Sep 3
To sum it up -- the patch introduces -fgpu-defer-diag flag which allows deferring overload resolution diagnostics, if overload set included candidates from both sides.
Wed, Aug 26
Aug 25 2020
Aug 24 2020
I'm OK with how the patch is implemented.
I'm still on the fence regarding whether it should be implemented.
How much does this inlining buy you in practice? I.e. what's a typical launch latency before/after the patch? For CUDA, config push/pop is negligible compared to the cost of actually launching the kernel on the GPU. It is measurable if the launch is asynchronous, but queueing kernels fast, does not help all that much in the long run -- you eventually have to run those kernels on the GPU, so in most cases you're just spend a bit more time idling while waiting for the queued kernels to finish. To be beneficial, you'll need a finely balanced CPU/GPU workload and that's rather hard to achieve. Not to the point where the minor savings here would be meaningful. I would assume the situation on AMD GPUs is not that different.
Aug 14 2020
Separated blocks of RUN commands with an empty line to make navigation easier.
Aug 13 2020
Couple of minor nits. LGTM otherwise.
Aug 11 2020
Looks good in general. Mostly C++ style comments below.
Aug 10 2020
The test is no longer sticking out: https://gist.github.com/Artem-B/d0b05c2e98a49158c02de23f7f4f0279
The fix is here https://reviews.llvm.org/D85686
We can restrict externalization to constant variables with explicit 'constant' attributes only, which should fix this issue.
Sam, just a FYI that the patch has a couple of unintended consequences.
Aug 7 2020
Aug 6 2020
Aug 5 2020
Also fixed the same bug in nearbyint().
LGTM for CUDA.
Aug 4 2020
What is expected to happen to device statics in anonymous name spaces? It may be worth adding them to the tests.
Jul 29 2020
LGTM, modulo couple of nits.
Also, do we need the header at all?
It would be much easier to just get clang itself to add normalized macros without trying to reconstruct them from the existing macros.
Jul 28 2020
I think Sam's approach is reasonable.
I'm not sure it's particularly useful, to be honest. CUDA code still needs to be compatible with NVCC so it can't be used in portable code like TF or other currently used CUDA libraries.
It could be useful internally, though, so I'm fine with it for that purpose.
Jul 27 2020
It's a good point. Perhaps this is one of the cases where we should *not* follow nvcc.
We can't have our cake (preserve static behavior) and eat it (treat it as non-static in case something on the host side may decide to use an API which uses symbol names). Something's got to give. While we could make it work in some cases, I don't think we can make it work consistently.
I think it would be reasonable to restrict APIs that access symbols by name to be applicable to visible symbols only.
Jul 24 2020
Updated directory structure.
Phabricator seems to be confused by the renames. The change just moved terraform -> terraform/buildbot-mlir-nvidia
The directory structure looks like this now:
Really updated directory structure.
Updated directory structure.
Jul 23 2020
Would it work if we generate a globally unique visible aliases for the static vars and use the alias' name to register device-side entities without changing their visibility?
I'm going to try the patch on our CUDA code and see how it fares. Stay tuned.
Jul 22 2020
Updated status.py with the new builder names.