This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.)
-- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |