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

[Paul Schlie]

> 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.)

Thanks, -paul-