>I'm not saying that we should ever >dereference an unaligned pointer.
>All I'm asking for is that pointer arithmetic >will be well-defined for
>all pointer types even when the address is >unaligned -- and I think
>this won't affect any optimisers. In fact it >won't even require a
>change to any modern compilers.

Correct....the only missing thing is the guarantee that it works same way on all platfroms.

>By the way I do realise that this will all fall >apart when it comes to
>"pointer tagging". If someone uses the lower >3 bits of a pointer to
>store extra info, and if I then relocate the >object into unaligned
>memory and do arithmetic on a pointer inside >it, then I'll corrupt the
>pointer tag. I realise that.

That's not a problem,  because if you want to tag a pointer you need to wrap it inside a structure, and you can delete all member operators that modify the pointer value inside that structure.
And when you want to get the raw pointer back, you just mask out the tag bits, and get the pointer bits intact.

Maybe you should reformulate your thread's question. Instead of asking for the feature, maybe ask who is breaking it, if there is none, then it can be standardized.

Sent from my Galaxy


-------- Original message --------
From: Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org>
Date: 1/29/25 1:39 PM (GMT+01:00)
To: std-proposals@lists.isocpp.org
Cc: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>
Subject: Re: [std-proposals] Make all data pointers intercompatible

On Tue, Jan 28, 2025 at 3:40 PM Jens Maurer wrote:
>
> >     double *ptr = reinterpret_cast<double*>(0x7fff934a9d83);
> >
> > Then I want "++ptr" to add 8 to it, giving 0x7FFF934A9D8B. I want this
> > to be well-defined behaviour.
>
> It is an important optimizer assumption that all values
> of a given type "pointer to T" are suitably aligned for "T".


I've been mulling this over. Let's say we have a double*, and that
alignof(double) == 8.

If we increment this pointer or do any arithmetic on it, then an
x86_64 CPU will simply do:

    add rdi, 8

There isn't any optimisation that can be performed here. I can't think
of another CPU that would do something differently that would allow
for any kind of optimisation here.

But when it comes to dereferencing the pointer, this is where
optimisation can come into it. There is the "movsd" instruction for
moving a floating-point number:

    movsd xmm0, [aligned address]

And then there's the "movups" instruction for moving a floating-point
into unaligned memory:

    movups xmm0, [unaligned address]

I'm not saying that we should ever dereference an unaligned pointer.
All I'm asking for is that pointer arithmetic will be well-defined for
all pointer types even when the address is unaligned -- and I think
this won't affect any optimisers. In fact it won't even require a
change to any modern compilers.

By the way I do realise that this will all fall apart when it comes to
"pointer tagging". If someone uses the lower 3 bits of a pointer to
store extra info, and if I then relocate the object into unaligned
memory and do arithmetic on a pointer inside it, then I'll corrupt the
pointer tag. I realise that.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals