[llvm-dev] RFC: A change in InstCombine canonical form

[Ehsan Amiri via llvm-dev]

On Tue, Mar 22, 2016 at 7:46 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> ------------------------------
>
>
>
>
> I think typeless pointer, will automatically makes it obsolete. Remember,
> I proposed to make a change "when we load a value of type T from a type T*
> memory address". There will not be a type T * memory address, once typeless
> pointer work is in.
>
> When we transform a small memcpy into a pair of load and store
> instructions, we'll still need to pick a type. Currently, as I understand
> it, we always pick integers. It is proposed to use the original type
> instead. Once we have typeless pointers, how will we pick the type? If the
> answer is that we'll always use integers, then I suppose this is temporary.
> Otherwise, not. Does that accurately represent the situation?
>
>
The way I understand it is temporary. (Using Hal's wording)






>  -Hal
>
>
>
>
>> --
>> Mehdi
>>
>>
>>
>>
>>
>> On Tue, Mar 22, 2016 at 6:58 PM, James Y Knight <jyknight at google.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Mar 22, 2016 at 5:44 PM, Ehsan Amiri via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Thanks.
>>>>
>>>> *Phillip, *As Hal said I do not think (1) is a very large item. Please
>>>> let me know if I am mistaken.
>>>>
>>>> *David *I think (1) is more inline with typeless pointer work than
>>>> (2). Contributing to typeless pointer work will be great, but given its
>>>> unknown time frame we cannot stop fixing existing problems. Of course, we
>>>> should follow an approach consistent with the long-term solution.
>>>>
>>>
>>> It seems to me that the question to ask is what would be the best state
>>> of the code, assuming that the typeless pointers work had already been
>>> done. Is it the current canonical form? Or the newly proposed one?
>>>
>>> I think it'd be the current one? If so, I'd suggest that proposal #2 is
>>> more compatible with the typeless pointer work. That is because (if done
>>> properly), code which knows how to look through pointer bitcast nodes is
>>> something which will be much more easily deletable once pointer bitcast
>>> nodes cease to exist, than to change the canonicalization of memcpy back
>>> and remove any backend code which was added only to compensate for that
>>> change.
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/e438f405/attachment.html>