[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