[llvm-dev] Which pass should be propagating memory copies

[Keno Fischer via llvm-dev]

Well, mostly I want to hoist the store to the stack and transform it into a
store to the heap. After that the memcpys are essentially trivially dead,
so instcombine or dse will delete them for me. If the memcpys were made of
individual stores instead, there'd have to be some sort of exponential
search somewhere in the compiler to figure that out. For the extreme case
consider [100000000 x double]. The same optimization can apply here, but if
it tried to do 100000000 stores instead, I wouldn't expect the compiler to
really figure that out. What I meant was that I think the memcpys are the
correct representation of this from the frontend, it's just that I'd like
more optimization to happen here.


On Wed, May 17, 2017 at 11:48 AM, Peter Lawrence <peterl95124 at sbcglobal.net>
wrote:

> Keno,
>           "No, I very much want the memcpys there” seems like a
> contradiction,
> Aren’t you trying to optimize away the memcpys.
> Peter Lawrence
>
>
>
>
>
>
> On May 17, 2017, at 8:22 AM, Keno Fischer <keno at juliacomputing.com> wrote:
>
>
> On Wed, May 17, 2017 at 12:09 AM, Peter Lawrence via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Keno,
>>           Perhaps you can view the problem to be the memcpys themselves,
>> We humans can look at the memcpys and see loads and stores
>> but to almost all optimizer passes they aren’t what it is looking for,
>> They instead see function calls which they mostly don’t touch,
>>
>> If these memcpys were inlined into plain old loads and stores
>> The redundant loads and stores should be deleted by existing opts
>>
>> A question I have for you is, because this looks like “copy-in-copy-out”
>> argument semantics,
>> Which to me looks more like Ada than C, what was the source language ?
>>
>>
>> Peter Lawrence.
>>
>
> No, I very much want the memcpys there. With individual stores I'd give up
> hope that the optimizer can figure out what's going on here, esp. if it
> gets beyond a few bytes, but I with memcpys it does seem doable. As for
> which frontend produced this, we're considering adding language semantics
> that would produce lots of code like this to julia, so we're looking into
> getting the optimizer to fold the extra copies away.
>
> Keno
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170517/14b0b699/attachment.html>