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

[Paul Schlie <schlie at comcast dot net>]

> From: Steven Bosscher <stevenb@suse.de>
>> On Saturday 16 April 2005 23:33, John David Anglin wrote:
>>>> Steven Bosscher
>>>> 
>>>>> On Saturday 16 April 2005 16:36, Roger Sayle wrote:
>>>>> Converting "ptr + strlen(ptr)" into "ptr + (char*)strlen(ptr)" in
>>>>> builtins.c, just appears a little strange at first sight.
>>>> 
>>>> Why does this appear strange?  It just makes the semantics of
>>>> pointer addition explicit.
>> 
>> It appears strange.  If I encounter this in the backend, the result
>> has to be loaded into a register and we probably loose an opportunity
>> to do an indexed load or store.
> 
> 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.

As such, conversely, it's likely more optimal for GCC to adopt a more
specifically typed machine model as it's basis, which can be mapped into
simpler machines as required.  Which supports the specification of logically
distinct and more strongly typed pointer objects, which although may seem
extreme, but since pointers seem to truly only require 4 basic operations:
(- ptr:type ptr:type) => offset:type, (+ ptr:type offset:type) => ptr:type
(mem ptr:type) => datum:type, and datum:type => (mem ptr:type); it seems
reasonable to consider. Correspondingly it may even be beneficial to more
strongly specify the signed vs. unsigned integer types as being distinct
types, as opposed to relying on separate and memory consuming cast operators
to designate the signess of an integer types distinct from their size, (just
as float types are distinct from integer types).

And ideally, GCC ideally truly needs to be able to model parallel sets and
dependencies more versatilly, not only to properly enable the accurate
representation of older target implied parallel condition code generation
and dependencies, but also to enable the analysis and optimization
instruction sets with increasing intra-instruction level parallelism in
general, as instructions are becoming more complex again, not simpler.
(Possibly becoming increasingly type specific, with likely increasing
numbers of parallel dependencies which will need to be tracked to enable
their optimal scheduling.)