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

[Paul Schlie <schlie at comcast dot net>]

> From: Chris Lattner <sabre@nondot.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.
> ...
> 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.

Thank you, (it should be interesting to see how things evolve through time
as hopeful support for Harvard and SIMD/VLIW target architectures mature).