<div dir="ltr">Hi Rafael,<br><br>The changes to the mips fast isel test are worrying. From looking at the testcase it's materializing a constant 1 and you have it now materializing a constant -1 (extended) into the register.<div><br></div><div>-eric</div></div><br><div class="gmail_quote">On Mon, Apr 6, 2015 at 12:00 PM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ping<br>
<br>
On 2 April 2015 at 13:28, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
> ping<br>
><br>
> On 27 March 2015 at 14:00, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>> ping<br>
>><br>
>> On 18 March 2015 at 11:45, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
>>> Fast isel currently has a bug in that it zero extends immediates to 64<br>
>>> bits. This normally goes unnoticed because the value is truncated to<br>
>>> 32 bits for output.<br>
>>><br>
>>> Two cases were it is noticed:<br>
>>><br>
>>> * We fail to use smaller encodings.<br>
>>> * If the original constant was smaller than i32.<br>
>>><br>
>>> For example, the only possible values for i1 are 0 and -1, yet we were<br>
>>> expanding -1 to i32 1.<br>
>>><br>
>>> Cheers,<br>
>>> Rafael<br>
</blockquote></div>