Brain dump on type merging

[Philip Reames]

On 12/04/2014 09:12 AM, David Blaikie wrote:
>
>
> On Thu, Dec 4, 2014 at 1:23 AM, Chandler Carruth <chandlerc at google.com 
> <mailto:chandlerc at google.com>> wrote:
>
>
>     On Thu, Dec 4, 2014 at 1:18 AM, Hal Finkel <hfinkel at anl.gov
>     <mailto:hfinkel at anl.gov>> wrote:
>
>         +1 -- We don't need types on pointers -- they don't convey any
>         information to the optimizer. FWIW, it would not surprise me
>         if the elimination of all of the unnecessary pointer bitcasts
>         produces measurable compile-time savings.
>
>
>     Indeed.
>
>     I'm actually interested in looking at this if no one else gets to
>     it first. (for me, it's after the pass manager at the least) If
>     someone else is able to hack on this though, it would be awesome.
>     I think it'll actually help LTO quite a lot by reducing the
>     footprint of the IR.
>
>
> This sounds potentially like the sort of monkey work I could do/dabble 
> in - might chat with you more about it to see if I'm figuring that 
> correctly before diving in.
A couple of comments on the thread so far:
- Semantically, I have no objection to the removal of the type from the 
pointer.  I agree that this gets us very little and gives a deceptive 
appearance of type safety where there is none.  The only strong 
distinction between pointer types is via address spaces; as long as 
that's preserved, I have no objection.
- From a readability perspective, typed pointers do actually help a 
lot.  Looking at the IR and figuring out what a particular pointer 
describes would be far harder without them.  If we do move to a typeless 
pointer, I would argue in favor of having the types still be present, 
but make it legal to cast between pointer types without a bitcast.  
(i.e. all pointer 'names' refer to a single underlying type)
- This is a large enough change in the IR that a true proposal should be 
sent to the mailing list & given a week or two to propagate before any 
work is done.


>
>     _______________________________________________
>     llvm-commits mailing list
>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141204/21e76123/attachment.html>