[LLVMdev] Aggregate store/load optimization

deadal nix deadalnix at gmail.com
Mon Sep 29 22:06:04 PDT 2014


Ok I can try to make something in a new pass.

2014-09-29 9:58 GMT-07:00 Reid Kleckner <rnk at google.com>:

> 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/bf1eb09d/attachment.html>


More information about the llvm-dev mailing list