[cfe-commits] [llvm-commits] TableGen backend API refactoring review request

Chandler Carruth chandlerc at google.com
Thu Jun 21 08:31:55 PDT 2012


On Thu, Jun 21, 2012 at 8:25 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Jun 21, 2012, at 1:04 AM, Chandler Carruth <chandlerc at google.com>
> wrote:
>
> The hash function should never be relied on to be deterministic. One of
> these days I'm going to have the stones to flip a switch and the hash
> function will produce different values on each execution with high
> probability.
>
>
> Why?! Nondeterministic behavior is notoriously hard to track down, why
> would you want to add more of it?
>

To make it easier to track down? Specifically, this should make any
behavior which could change every 1 in N builds likely to change *every*
build, so it can be caught with a single bootstrap.


> You would be adding bugs where one in 20 compilations of the same source
> produces different output. Buildbots aren't going to help you find the
> offending commit.
>

The change I'm proposing (which we should probably discuss in a different
thread as this is getting off topic) wouldn't cause 1-in-20 bugs. If it
changes behavior at all, it will cause *every* compilation to be different
with a very high probability. This should make a single bootstrap have a
high probability of finding the bug, and with more than 1 bootstrapping
build bot, we should find it immediately?


All this said, I'm clearly not going to blindly turn this on. ;] First off,
we're not ready, and second off, it'll take quite some time experimenting,
fixing bugs, checking that we get things correct, etc. There is no rushing
here, it's just a long-term goal of mine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120621/2675ae23/attachment.html>


More information about the cfe-commits mailing list