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

[Keno Fischer via llvm-dev]

Argh, I'm sorry. I realize the original IR has the most unfortunate typo.
What I meant was
that the intermediate store should have happened on the stack, i.e.

 %dataptr = getelementptr inbounds [4 x double], [4 x double] *%stack, i32
0, i64 %idx

I'm sorry for any confusion that caused.

On Wed, May 17, 2017 at 11:55 AM, Keno Fischer <keno at juliacomputing.com>
wrote:

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