Hi rafael,<div>I think the logs with just -early-cse -sroa is different from one reported in pr18615. Although i think both are fixed by this patch. I added -instcombine as it results in same crash log as reported in pr18615.</div>
<div>I will recheck it once again and may be we can run both these transformations in the test case?</div><div>Thanks</div><div>Karthik Bhat<br></div><div><br></div>On Friday, February 21, 2014, 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">On 20 February 2014 05:46, Karthik Bhat <<a href="javascript:;" onclick="_e(event, 'cvml', 'kv.bhat@samsung.com')">kv.bhat@samsung.com</a>> wrote:<br>

>   Hi Rafael,Chandler,<br>
>   I was revisiting the patch and looking into SROA in more detail. I think the check was in incorrect position.<br>
>   If we have a out-of-bounds access in memtransfer we should never add the instruction into MemTransferSliceMap and also remove any instruction on the other side of the transfer if already added to MemTransferSliceMap.<br>

>   The problem in the current code seems to be that in visitMemTransferInst while checking for out of bounds we are just checking the upper bound and not the case were offset is negative.<br>
>   Added code to check the same. Please let me know your inputs on the same as i'm a bit new to optimization code.<br>
<br>
The test can be reduced a bit more. I noticed that just "-early-cse<br>
-sroa" would crash, and feeding the output of -early-cse run to just<br>
-sroa crashes it too. I then just simplified it by hand a bit more<br>
(attached).<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote>