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

[Ehsan Amiri via llvm-dev]

On Tue, Mar 22, 2016 at 7:33 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

>
> On Mar 22, 2016, at 4:15 PM, Ehsan Amiri via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> James,
>
> I think (1) reduces the number of "do-not-see-through-bitcast" bugs that
> we need to uncover and fix between now and the time that typeless pointer
> is available. That means it is likely that we have multiple such fixes in
> the code and then we have to remove each one of them. (And means each one
> of those has to be done properly to be easily remove-able).
>
> Changing canonicaliztion of memcpy, will be removing a couple of lines of
> code. I am not sure about the size of backend changes to optimize
> load-store patterns. But I expect it to be small.
>
>
> Are you saying that the canonicalization you want to change is temporary
> till we get the typeless pointers?
>
>
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.




> --
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160322/1febbe40/attachment.html>