Re: [PATCH 1/5] do not corrupt ptrlist while killing unreachable BBs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7 July 2017 at 10:44, Christopher Li <sparse@xxxxxxxxxxx> wrote:
> On Fri, Jul 7, 2017 at 2:19 AM, Dibyendu Majumdar
> <mobile@xxxxxxxxxxxxxxx> wrote:
>> On 7 July 2017 at 07:02, Christopher Li <sparse@xxxxxxxxxxx> wrote:
>>
>> Anyway - here is a snippet from my modified ptrlist implementation.
>>
>> /* Each node in the list */
>> struct ptr_list {
>> int nr_;
>> struct ptr_list *prev_;
>> struct ptr_list *next_;
>> struct allocator *allocator_;
>> void *list_[LIST_NODE_NR];
>> };
>>
>> struct ptr_list_iter {
>> struct ptr_list *__head;
>> struct ptr_list *__list;
>> int __nr;
>> };
>
> I try exactly that before.
>
> The problem with that is, it generate horrible code.
> I never able to teach gcc the member of the list_iter
> does not need to sync at memory boundary. I really
> want it to be register like.
>
>>
>> #define FOR_EACH_PTR(list, var) \
>> { struct ptr_list_iter var##iter__ = ptrlist_forward_iterator(list); \
>> for (var = ptrlist_iter_next(&var##iter__); var != NULL; var =
>> ptrlist_iter_next(&var##iter__))
>> #define FOR_EACH_PTR_TYPED(list, type, var) \
>> { struct ptr_list_iter var##iter__ = ptrlist_forward_iterator(list); \
>> for (var = (type) ptrlist_iter_next(&var##iter__); var != NULL; var =
>> (type) ptrlist_iter_next(&var##iter__))
>> #define FOR_EACH_PTR_TYPE(list, var, ptr_type) \
>> { struct ptr_list_iter var##iter__ = ptrlist_forward_iterator(list); \
>> for (var = (ptr_type) ptrlist_iter_next(&var##iter__); var != NULL;
>> var = (ptr_type) ptrlist_iter_next(&var##iter__))
>> #define END_FOR_EACH_PTR(var) }
>>
>> #define FOR_EACH_PTR_REVERSE(list, var) \
>> { struct ptr_list_iter var##iter__ = ptrlist_reverse_iterator(list); \
>> for (var = ptrlist_iter_prev(&var##iter__); var != NULL; var =
>> ptrlist_iter_prev(&var##iter__))
>> #define END_FOR_EACH_PTR_REVERSE(var) }
>
> The problem with this is that, once you put delete into mix.
> The iter will need to know which direction it need to go after
> the delete. It is actually very messy.
>
>  I end up abandon that approach.

I am using this without problems in dmr_C so not sure I understand why
it did not work.

Regards
Dibyendu
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Newbies FAQ]     [LKML]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Trinity Fuzzer Tool]

  Powered by Linux