[PATCH 1/9] R600/SI: fix stupid typo

Hal Finkel hfinkel at anl.gov
Tue Feb 26 06:05:20 PST 2013


----- Original Message -----
> From: "Christian König" <deathsimple at vodafone.de>
> To: "Sean Silva" <silvas at purdue.edu>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Tuesday, February 26, 2013 4:18:20 AM
> Subject: Re: [PATCH 1/9] R600/SI: fix stupid typo
> 
> 
> 
> Am 26.02.2013 03:33, schrieb Sean Silva:
> 
> 
> 
> On Mon, Feb 25, 2013 at 3:00 PM, Tom Stellard < tom at stellard.net >
> wrote:
> 
> 
> 
> 
> Can you clarify this? Do you mean one email with with all the patches
> as attachments?
> 
> That would be preferable. Note that gmail (which many of us use)
> doesn't respect threading (instead it arbitrarily threads based on
> subject for some reason), so having them all as replies will still
> flood the inbox of gmail users.
> 
> 
> That's the exactly opposite policy as many other open source
> development list use, the argument pro in-lining patches is usually
> that the code is easier to comment on. But personally I usually also
> prefer some form of one mail (or one thread) per patchset for
> review.
> 
> 
> 
> 
> 
> However, it is much more in line with LLVM development style to send
> in patches incrementally for review rather than dumping a whole
> branch; that ensures focused review.
> Those patches belong together and either implement new features or
> fix bugs that were triggered/found while implementing those new
> features. Reviewing them separately would just increase the chance
> of missing something regarding inter patch dependency.
> 
> 
> 
> 
> 
> (I'll also reiterate how troubling it is that none of these R600
> changes have unit tests).
> 
> Totally agree on that, the major problem seems to be that currently
> the instruction scheduler and/or register allocator produce
> different results when compiling the same code twice. The results
> seems to be always correct, it's just not very well comparable. That
> fact makes it quite difficult for me to write profound unit tests.
> Any ideas on that?

These components should be deterministic. If you can't already find a suitable open bug report, please file one with some examples.

 -Hal

> 
> Christian.
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 




More information about the llvm-commits mailing list