- User Since
- Apr 16 2015, 7:54 AM (248 w, 1 d)
Wed, Jan 15
Having a copy function per type allows us to reuse it, otherwise we have one copy function per static task location (at worst). Either works for me I think.
I also would be OK with either option.
But note that using per-type functions will require more additions to the interface, like:
(..., num_objects, array_of_copy_wrappers, array_of_desctuctor_wrappers, array_of_obj_offsets).
Then the library can iterate over objects to copy-construct them, then iterate to destroy them after the task is complete. Without any possibility of inlining of any wrappers.
Tue, Jan 14
the task create and task issue step are
conceptually not separated anymore as it is
I don't think this can work reliably. Because not all C++ objects can be mem-copied.
E.g. an object can keep its own address or reference, and mem-copy will make it broken.
This could be fixed by generating (optional) thunk routine which would create all needed objects
in the library-allocated space, and similar routine which would destroy all the created objects.
Nov 27 2019
Nov 26 2019
Nov 25 2019
I am not an ARM expert, but don't see any problems with checking extra define here.
Nov 19 2019
Nov 18 2019
Nov 13 2019
Nov 7 2019
Looks acceptable to me. As well as removing the kmp_internal_end_fini symbol at all, as it duplicates the functionality of kmp_internal_end_dtor which has attribute "destructor". I am OK with either solution, would be good to hear others opinion.
Oct 30 2019
Oct 25 2019
Oct 8 2019
you may want to ask for D68045 landing there directly, as compiler-rt is a different project which I don't work on.
Sep 27 2019
Sep 25 2019
Sep 16 2019
Sep 4 2019
Sep 3 2019
BTW, there is also workaround without runtime patching, - set KMP_TEAMS_THREAD_LIMIT to the same value as OMP_THREAD_LIMIT. This avoids runtime segfault with old library.
Sep 2 2019
Aug 16 2019
Aug 12 2019
Aug 7 2019
Aug 6 2019
Jul 29 2019
Jul 26 2019
I will contact ittnotify owners just in case. So that we might have lesser burden with possible future updates of this third-party code.
Jul 25 2019
LGTM (I'd treat this as NFC :).
Jul 16 2019
Jul 12 2019
Jul 10 2019
Jul 2 2019
Jun 27 2019
Of cause you are free to choose your own test, or simply extend existing test(s).
Jun 26 2019
Yes, adding tests would be great. Simplest thing to do is to extend existing tests with throttling on/off, I think.
Jun 25 2019
sorry for the delay.
Jun 21 2019
Covered more cases caused memory leak (when target-teams region is followed by parallel with bigger number of threads) and use-after-free problem (when nested hot teams requested via KMP_HOT_TEAMS_MAX_LEVEL=2 and num_teams is bigger than 1). The leak is fixed by freeing CG structure when worker threads inherit master's CG but had earlier non-NULL CG. Use-after-free fixed by making one more freeing of CG conditional (in __kmp_free_team routine).
Jun 20 2019
Jun 19 2019
Addressed Joachim's comments.
Jun 5 2019
Review comments addressed:
- removed printf("passed") when the test is skipped;
- changed default size to lower/upper limit for consistency during size adjustment.
Jun 4 2019
Addressed Johannes' comment. At the same time I've reduced the upper bound of the size to be propagated to 64MB (from initial 256MB), because with this change more applications will be affected (those require big stack for master and small stack for workers).
Jun 3 2019
May 31 2019
Regarding test system,
Test fixed: added "return 1" on possible failure of the test.
Moved declaration of rlim under #if to avoid "unused variable" warning.
May 29 2019
May 28 2019
By negative test I meant the wrong value is ignored and the default used instead. I don't think we need to check library warnings.
Probably test case worth adding. Or even two, - one negative with something like "mandatorynot" value, another positive (we do have internal getter routine for the target-offload-var ICV).
May 27 2019
May 23 2019
May 22 2019
May 16 2019
May 15 2019
I actually was not able to reproduce your first problem. But I hope the patch should fix both.
May 13 2019
Sorry for committing the broken patch with missed ")" and "eol". Should now be fixed by r360602.
May 8 2019
Apr 30 2019
Apr 22 2019
Apr 19 2019
Not sure this is a good change, e.g. gcc produces tons of warnings:
Apr 17 2019
Apr 15 2019
Apr 11 2019