qiyao wrote:
> My main concern with this is that it can lead to quadratic complexity under
> certain insertion patterns, and that it is making the L1 cache much more
> complicated. We probably need to use some better data structures to keep
> track of overlapping ranges and allow fast invalidation of all ranges mutated
> by a given write.
>
I thought about it, it was simpler indeed. My intuition tells me that is it
fragile to have a cache allowing overlap.
> A side note about the commenting style: if we were to keep this patch, I
> wanted to highlight that we are adding a new invariant to the L1 cache
> ("ranges are non overlapping"), and there are _many_ comments in the PR
> repeating this and using it to justify algorithmic decisions. IMO we would be
> better off having a single line in the header file stating that "the L1
> consists of non-overlapping segments", and virtually no comments inside the
> functions themselves.
>
I can simplify and re-organize them if we agree on this approach. When I
realized that the overlap chunk scenario wasn't considered when the L1 cache
was introduced *11 years ago*, I wanted to emphasize every step of the fix,
and make them clear.
https://github.com/llvm/llvm-project/pull/208347
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
