[PATCH] Fix Bug in SROA transformation [PR18615]

Karthik Bhat blitz.opensource at gmail.com
Thu Feb 20 16:42:24 PST 2014


Hi rafael,
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.
I will recheck it once again and may be we can run both these
transformations in the test case?
Thanks
Karthik Bhat

On Friday, February 21, 2014, Rafael EspĂ­ndola <rafael.espindola at gmail.com>
wrote:

> On 20 February 2014 05:46, Karthik Bhat <kv.bhat at samsung.com<javascript:;>>
> wrote:
> >   Hi Rafael,Chandler,
> >   I was revisiting the patch and looking into SROA in more detail. I
> think the check was in incorrect position.
> >   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.
> >   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.
> >   Added code to check the same. Please let me know your inputs on the
> same as i'm a bit new to optimization code.
>
> The test can be reduced a bit more. I noticed that just "-early-cse
> -sroa" would crash, and feeding the output of -early-cse run to just
> -sroa crashes it too. I then just simplified it by hand a bit more
> (attached).
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140221/affdc597/attachment.html>


More information about the llvm-commits mailing list