llvm dev - Mar 2016 - RFC: A change in InstCombine canonical form

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>

----- Original Message -----
> From: "Ehsan Amiri via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Tom
Stellard"
> <thomas.stellard at amd.com>, "Ulrich Weigand" <uweigand
at de.ibm.com>
> Sent: Tuesday, March 22, 2016 6:38:32 PM
> Subject: Re: [llvm-dev] RFC: A change in InstCombine canonical form
> 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.
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?

-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/0cb9bd48/attachment-0001.html>

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>