<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 26, 2014 at 10:59 AM, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Nov 26, 2014 at 10:56 AM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
> On Wed, Nov 26, 2014 at 10:39 AM, Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>> wrote:<br>
>><br>
>> The i965 backends pass something out of 'screen', which is allocated<br>
>> per-process, making using this as a ralloc context not thread-safe.<br>
>><br>
>> All callers ra_alloc_interference_graph() already ralloc_free() its<br>
>> return value.<br>
>> ---<br>
>>  src/util/register_allocate.c | 2 +-<br>
>>  1 file changed, 1 insertion(+), 1 deletion(-)<br>
>><br>
>> diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c<br>
>> index 6cf7ce7..1cfd66f 100644<br>
>> --- a/src/util/register_allocate.c<br>
>> +++ b/src/util/register_allocate.c<br>
>> @@ -374,7 +374,7 @@ ra_alloc_interference_graph(struct ra_regs *regs,<br>
>> unsigned int count)<br>
>>     struct ra_graph *g;<br>
>>     unsigned int i;<br>
>><br>
>> -   g = rzalloc(regs, struct ra_graph);<br>
>> +   g = rzalloc(NULL, struct ra_graph);<br>
><br>
><br>
> Why not make ra_alloc_interference_graph take a ralloc context?<br>
<br>
</span>I mean, I could, but why? All callers of ra_alloc_interference_graph()<br>
ralloc_free its result themselves.<br></blockquote><div><br></div><div>Sure.  It doesn't much matter.  It just gives us the option.  I don't care much either way.  This one is<br></div><div>Reviewed-by: Jason Ekstrand <<a href="mailto:jason.ekstrand@intel.com">jason.ekstrand@intel.com</a>> <br></div></div><br></div></div>