Re: [patch] builtins.c, fold-const.c: Don't create type

[Chris Lattner <sabre at nondot dot org>]

On Sun, 17 Apr 2005, Paul Schlie wrote:
> > From: Chris Lattner <sabre@nondot.org>
> > > On Sat, 16 Apr 2005, Paul Schlie wrote:
> > > > On IRC, Chris Lattner mentioned (if I understood him correctly) that in
> > > > LLVM this kind of pointer arithmetic doesn't exist, and that instead it
> > > > is converted to "regular" integer arithmatic by casting the pointer to
> > > > intptr_t (instead of casting the integer to a pointer).  Would that be
> > > > a better solution for GCC too, perhaps?
> > >
> > > Unfortunately, as the LLVM does not seem to differentiate between pointers
> > > to data (ram-heap-stack/rom-literal-data) vs. code (labels/functions); it's
> > > only capable of representing the simplest Von Newman machines; which is a
> > > fine for a simulated "virtual machine" target, but not likely a worthy basis
> > > for a "target-able" compiler model; as more specifically partitioned
> > > machines require correspondingly specific types of objects specified by the
> > > program to be retained to optimally map the program to their architectures.
> >
> > I'm sorry, but this claim is simply not true.
>
> Sorry, from the best I can tell from the documentation, LLVM seems to
> presume a single unified address space (with the exception of supporting a
> distinct I/O port address space)?  So although getelementptr may return an
> arbitrary and potentially non-unique addresses for function*, global-const*,
> allocated-vars*, etc., as they may be mapped into orthogonal address spaces;
> how does it enable correspondingly unique instruction access sequences to be
> generated for each of these potentially corresponding orthogonal address
> references? (I apologize if I've missed something that should be obvious.)

It's probably very off-topic for this list, but LlVM is fully typed (i.e. 
function pointers are distinct from data pointers), and it's immediately 
obvious what *direct* function/global var pointers point to.  We do not 
(yet) have support for separated address spaces where load/store 
instructions needs to be generate differently than normal load/stores 
(e.g. SPARC alternate address spaces).  AFAIK, neither does GCC, though 
its likely that I'm not aware of some target-specific attributes for this 
sort of thing.

In any case, this is unrelated to the original comment about support for 
IA64/PA function pointers, which I believe we do fully support.  The 
original question was whether we handle "ptr + int" distinctly from 
"ptr+ptr" or "int+int".  The answer is yes: we directly support "ptr+int" 
with getelementptr.  We do not support "ptr+ptr" (you need to cast one or 
the other to an integer). We do support "int+int" with the 'add' 
instruction.

Like most progress in LLVM, support will be added for alternate address 
spaces when someone feels the burning need for it.  We don't add features 
that noone wants or needs yet.

-Chris

--
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/