[PATCH] D27152: Merge strings using sharded hash tables.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Sun Dec 11 17:21:10 PST 2016


On Sun, Dec 11, 2016 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote:

> On Sat, Dec 10, 2016 at 3:41 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Sat, Dec 10, 2016 at 2:51 PM, Rafael Avila de Espindola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> Rui Ueyama <ruiu at google.com> writes:
>>> >
>>> > This means we produce different results with threads disabled?
>>> >
>>> >
>>> > Yes. But as long as you pass the same command line arguments, results
>>> are
>>> > the same.
>>>
>>> That is still undesirable. Using --no-threads is convenient for
>>> debugging and it makes it harder if that produces a different result.
>>>
>>>
>> This is basically a policy decision. Is `--threads`/`--no-threads`
>> allowed to affect the output? Whatever we decide, we should document the
>> decision because it has pretty profound consequences.
>>
>
> We could define a policy per a flag, but that's probably too complicated.
> I'd propose the following simple policy.
>
> "We guarantee LLD to produce the exact same result if the same input files
> and the same command line arguments are given in the same order."
>
> It's easy to remember and should suffice from the users' perspective.
>

That is the rule that I am in favor of, but Rafael seems to prefer that
--threads/--no-threads should not affect the output. Hence we need to come
to agreement and document the conclusion.

Also, the wording should be clear that the output *binary* is guaranteed
the same. We are already nondeterministic w.r.t. the order of user
diagnostics.

-- Sean Silva


>
> (although I think that our build ID already ends up different for
>> threads/no-threads?)
>>
>
> We always compute a tree hash, so the build-id is not affected by
> threads/no-threads.
>
> -- Sean Silva
>>
>>
>>
>>> Cheers,
>>> Rafael
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161211/123752ca/attachment.html>


More information about the llvm-commits mailing list