Hi all, One area where LLVM suck pretty badly is aggregate store and loads. clang do not use them so there are not seen as important, and aren't handled nicely. Other frontends work around the issue as it is not handled properly and we ends up with some kind of chicken and egg issue. I recently proposed a diff to be able to optimize load from aggregate stores in GVN without great success. Interest was unclear to some and alteration of GVN was a concern to many. I'd like to improve the aggregate support. SROA is deaggregating from alloca. Would the same approach for other loads./store be preferable ? That would give a way to use the existing infrastructure while providing a good support for aggregate. If yes, what would be the right place and way to do this ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140920/aa21b6be/attachment.html>
ping ? 2014-09-20 23:42 GMT-07:00 deadal nix <deadalnix at gmail.com>:> Hi all, > > One area where LLVM suck pretty badly is aggregate store and loads. clang > do not use them so there are not seen as important, and aren't handled > nicely. Other frontends work around the issue as it is not handled properly > and we ends up with some kind of chicken and egg issue. > > I recently proposed a diff to be able to optimize load from aggregate > stores in GVN without great success. Interest was unclear to some and > alteration of GVN was a concern to many. > > I'd like to improve the aggregate support. SROA is deaggregating from > alloca. Would the same approach for other loads./store be preferable ? That > would give a way to use the existing infrastructure while providing a good > support for aggregate. > > If yes, what would be the right place and way to do this ? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140928/04ffd6e3/attachment.html>
On 21 September 2014 07:42, deadal nix <deadalnix at gmail.com> wrote:> One area where LLVM suck pretty badly is aggregate store and loads. clang do > not use them so there are not seen as important, and aren't handled nicely. > Other frontends work around the issue as it is not handled properly and we > ends up with some kind of chicken and egg issue.Pardon my ignorance, but wouldn't that be a target-specific issue? cheers, --renato
I think in general, yes, this is probably the right way to optimize aggregate loads and stores. Most people agree that it is more canonical to use scalar loads and stores, so it's reasonable to transform one to the other. I'm not sure SROA is the right place to handle this, though. I believe it only operates on structures allocated on the stack. If you want to load and store to the heap, you'll need a different pass. On Sun, Sep 28, 2014 at 12:46 AM, deadal nix <deadalnix at gmail.com> wrote:> ping ? > > 2014-09-20 23:42 GMT-07:00 deadal nix <deadalnix at gmail.com>: > > Hi all, >> >> One area where LLVM suck pretty badly is aggregate store and loads. clang >> do not use them so there are not seen as important, and aren't handled >> nicely. Other frontends work around the issue as it is not handled properly >> and we ends up with some kind of chicken and egg issue. >> >> I recently proposed a diff to be able to optimize load from aggregate >> stores in GVN without great success. Interest was unclear to some and >> alteration of GVN was a concern to many. >> >> I'd like to improve the aggregate support. SROA is deaggregating from >> alloca. Would the same approach for other loads./store be preferable ? That >> would give a way to use the existing infrastructure while providing a good >> support for aggregate. >> >> If yes, what would be the right place and way to do this ? >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140929/93d45055/attachment.html>
It depends on the data layout, but the optimizer knows that. 2014-09-29 1:31 GMT-07:00 Renato Golin <renato.golin at linaro.org>:> On 21 September 2014 07:42, deadal nix <deadalnix at gmail.com> wrote: > > One area where LLVM suck pretty badly is aggregate store and loads. > clang do > > not use them so there are not seen as important, and aren't handled > nicely. > > Other frontends work around the issue as it is not handled properly and > we > > ends up with some kind of chicken and egg issue. > > Pardon my ignorance, but wouldn't that be a target-specific issue? > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140929/9bec358b/attachment.html>