On Fri, Dec 04, 2020 at 10:15:46PM +0800, Chung-Lin Tang wrote:
> this is a new version of the structure element mapping patch for OpenMP 5.0
> requirement
> changes.
Sorry for the delay.
> + /* Unified reference count for structure element siblings, this is used
> + when REFCOUNT_STRUCTELEM_FIRST_P(k->refcount) == true, the first
> sibling
> + in a structure element sibling list item sequence. */
> + uintptr_t structelem_refcount;
> +
> + /* When REFCOUNT_STRUCTELEM_P (k->refcount) == true, this field points
REFCOUNT_STRUCTELEM_P (k->refcount) is true even for
REFCOUNT_STRUCTELEM_FIRST_P(k->refcount), so shouldn't the description say
that structelem_refcount_ptr is only used if
REFCOUNT_STRUCTELEM_P (k->refcount) && !REFCOUNT_STRUCTELEM_FIRST_P
(k->refcount)
?
> + into the (above) structelem_refcount field of the _FIRST
> splay_tree_key,
> + the first key in the created sequence. All structure element siblings
> + share a single refcount in this manner. Since these two fields won't
> be
> + used at the same time, they are stashed in a union. */
> + uintptr_t *structelem_refcount_ptr;
> + };
> struct splay_tree_aux *aux;
> };
>
> /* The comparison function. */
Anyway, most of the patch looks good, but I'd like to understand the
rationale for choosing a htab over what I've been trying to suggest, which
was essentially instead of incrementing or decrementing refcounts push them
into a vector for later incrementing/decrementing, then qsort the vector
(by the pointers to refcounts) and increment what the elements point to unless
the same address has been incremented/decremented already.
Jakub
