- User Since
- Nov 6 2013, 8:48 AM (515 w, 4 d)
Oct 10 2021
I don't feel it is different for OpenCL though... I am not in favour of repeating the same functionality for every language since the requirement will be likely identical. There is no timeline for when this functionality will be dropped so we have to assume that even though temporary it might be a solution for long enough.
Sep 12 2021
Aug 26 2021
@Anastasia I used to have svn commit access, but haven't committed anything for a long while in LLVM, so don't know if I can get them back to github by just asking. So, can you please commit these HIPSPV patches for us?
Jul 6 2021
Ok, thanks for clarification. Does it mean there is something we need to add to LLVM somewhere to make it work correctly? Would it be specific to Arm or generally for all CPU targets?
Jul 5 2021
The reason why we would like to fix it is that upstream clang has a crash currently when OpenCL sources are compiled for any Arm CPU: https://bugs.llvm.org/show_bug.cgi?id=50841. Do you have any other suggestions to avoid this problem?
FYI clang also emits kernel metadata that can be used to detect kernels...
Jun 29 2021
Does this break clSetKernelArg() for ARM CPUs in PoCL? I believe so far it has worked for ARM - just wondering why you decide to drop it now?
Oct 3 2018
I glimpsed over this without spotting anything crucial. My Clang code base knowledge is a bit lightweight though so you might want to wait for an another reviewer. On the other hand, the semantics seem to be retained so it might be safe to commit this in case the tests still pass.
Thanks for making this MD more robust! It is essential for the vectorization performance of pocl. Sorry for my slow response time.
Jun 1 2017
Committed in r304389.
May 29 2017
Added the requested AMDGCN test case.
Feb 13 2017
Feb 9 2017
Jan 23 2017
Jan 22 2017
Jan 18 2017
Jan 17 2017
Jan 13 2017
Jan 11 2017
Jan 10 2017
Dec 22 2016
Nov 14 2016
Committed in r286819.
Nov 7 2016
target architecture). So if there are no memory segments, nothing can be done to optimize for this and therefore providing
the "fake" segment information doesn't seem to be useful? I am just trying to understand the use case.
Nov 3 2016
Indeed, it requires wider scale discussion to get it right, and e.g. to pass the info to AA. But to be honest, I think OpenCL and CUDA are still considered 'minority' languages in Clang/LLVM which makes me usually lean towards least intrusive implementation solutions whenever possible.
Nov 2 2016
Nov 1 2016
Thanks. @tstellarAMD OK to commit for 3.9.1 as well?
Oct 31 2016
Sep 20 2016
Makes sense to me. How to differentiate between OpenCL implementations? With the OS setting?
May 17 2016
Mar 21 2016
Feb 23 2016
Feb 16 2016
Feb 15 2016
Feb 12 2016
Can you add a test that tries to use half precision constants in non OpenCL C mode? Otherwise LGTM.
Feb 11 2016
Feb 1 2016
Jan 25 2016
@pekka, do you think it would make sense to include a description of the new OpenCL features in the release note too? Or shall we wait for the completion of OpenCL 2.0 support (hopefully in next release)? Could do both as well I guess. :)
LGTM too. Good job. You can try and ask the release manager if you can sneak it in. It's rather container patch so there might be a chance, but I don't know the policy at this stage of the release.
Jan 14 2016
OK. Seems the LLVM 3.8 branching was done, it might be hard to get this in, but should we try and ask the release manager?
Jan 11 2016
Jan 9 2016
I wonder could we squeeze this in before the next week's LLVM 3.8 branching? It would be great.
Dec 30 2015
Dec 28 2015
Dec 15 2015
Nice! I will keep on trying to help by reviewing patches whenever time allows.
Dec 11 2015
Dec 4 2015
Is this still waiting for some updates?
Nov 12 2015
Nov 10 2015
Only small issues found, plus it could use some more test cases.
Oct 21 2015
Oct 2 2015
Sep 29 2015
Sep 27 2015
Sep 24 2015
Could only find style nitpicks in this one.
Sep 15 2015
We are interested in the pipe.
Sep 14 2015
The patch seems straightforward enough. BTW does someone know if anyone has worked on the 'pipe' qualifier?
Sep 8 2015
Sep 7 2015
Sep 3 2015
The fix looks good, but maybe the test should be an .ir test as this probably affects other targets than MIPS too? Also could be a candidate for 3.7.1?
Sep 2 2015
Is there a matching HLC-HSAIL branch for the latest version of the patch? It doesn't work with with hsail-stable-3.7 anymore.
Aug 26 2015
Perhaps the assert() is unneccessary, but otherwise LGTM.
Aug 3 2015
Can you please clarify me a bit where the actual device is needed/used (ATM only Kaveri) if the target is HSAIL, an "abstract machine"/IL? Just trying to get my head around on how the Clang/LLVM will work for HSAIL.
Feb 6 2015
Great to see this being worked on! It will help the implicit pocl work-group vectorization after the 2-level loop restricting is lifted. Related to this, be careful with the loop id metadata and especially the parallel loop metadata. The parallel loop metadata can be exploited to skip dependency analysis in some cases (At least when both of the loops are parallel? Needs to be thought through.). But if the metadata is moved to a wrong loop during the interchange it might result in a miscompilation.
Jan 29 2015
Are those if conditions that span to the next line indented correctly?
Jan 18 2015
Is this missing the pass itself?
Jun 10 2014
Great, this feature will be really useful. How about naming these metadatas using the llvm.loop. as a prefix? That is, llvm.loop.unroll.enable etc? Maybe it's worth adding a test case with a negative unroll count to ensure nothing bad happens. Otherwise LGTM.