Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: David Blaikie <dblaikie <at> gmail.com>
Subject: Moving towards a singular pointer type
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Friday 6th February 2015 23:38:23 UTC (over 3 years ago)
It's an idea been thrown around in a few different threads (including
Rafael's recent
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141201/247285.html
and Chandler's http://llvm.org/viewvc/llvm-project?rev=226781&view=rev
) so
I'm putting up my hand to volunteer to do the work & interested in getting
a bit more feedback, thoughts on best approaches, timing, etc.

For some more detail: pointer types (i32*, %foo*, etc) complicate IR
canonicalization. store + load should be the same instructions given the
same number of bytes stored to memory, but instead we can have store float,
store int, etc, etc. Another point Chandler made was that the bitcasts
involved when a pointer isn't of the right type results in extra IR
instructions we don't really need.

So the general idea is that all pointers would just be called "ptr"
(pointer? void*?).

Is this something everyone feels is the right direction? Any reason why it
wouldn't be?

Beyond that, I'm trying to think about how to do this & I haven't hit on a
terribly convincing way to do this incrementally. I could introduce the
alternative form of "store" that provides the magic pointer type, then set
about adding overloads (is that possible?) of any instruction consuming a
pointer type, writing the usual LLVM regression tests as I go. Eventually,
once this looks like it's functioning, I could start porting IRbuilder and
Clang over to the new store operations & other sources of pointers. Then
remove the old stuff.

Are IR instructions overloadable like this? If not, would it be worthwhile
to introduce separate names for the typeless-pointer forms (gep_ptr,
store_ptr, etc) as a temporary means to have both sets of semantics then
rename them all back once the old ones are removed?

Other ideas/thoughts?

- David
 
CD: 16ms