llvm dev - Jan 2019 - Reducing the number of ptrtoint/inttoptrs that are generated by LLVM

> As with many things in the C and C++ specifications, this has very
> little relationship to real-world code.  The biggest example I've seen
> that violates this rule is the way that the FreeBSD kernel implements
> per-CPU storage, but in a fairly ad-hoc analysis of existing C/C++ code
> we found quite a few cases where subtraction occurred between objects.
Hello David,
If C programmer wants to get distance between two different objects, s/he
can use (intptr_t)p - (intptr_t)q instead of p - q.
I believe this situation is similar to one adopting optimizations/analyses
that exploit signed overflow / TBAA / etc.

Juneyoung Lee

On Tue, Jan 15, 2019 at 11:59 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 14/01/2019 20:55, Juneyoung Lee via llvm-dev wrote:
> > Correctness of psub is guaranteed by the specification of pointer
> > subtraction of C/C++.
> > When two pointers are subtracted, both shall point to elements of the
> > same array object, or one past the last element of the array object
> > (6.5.6.9).
>
> As with many things in the C and C++ specifications, this has very
> little relationship to real-world code.  The biggest example I've seen
> that violates this rule is the way that the FreeBSD kernel implements
> per-CPU storage, but in a fairly ad-hoc analysis of existing C/C++ code
> we found quite a few cases where subtraction occurred between objects.
>
> David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/af240b11/attachment.html>

On 15/01/2019 16:26, Juneyoung Lee wrote:
> If C programmer wants to get distance between two different objects, 
> s/he can use (intptr_t)p - (intptr_t)q instead of p - q.
That's fine for new code, but unless you're volunteering to audit the 
(roughly) 8 billion lines of open source C code and a corresponding 
(probably larger) amount of proprietary code, then making this 
assumption is going to break things.

 From the relatively small survey that we did of C idioms as part of the 
CHERI project, I can tell you that this is very widespread.  This was 
something that we had to support (we considered only allowing pointer 
subtraction to yield a valid result when the operands referred to the 
same object and it broke pretty much everything we looked at).

David

P.S. If you want to talk about the standard with respect to intptr_t, 
you might want to reread what the standard actually says about it, 
specifically that a) it's optional, and b) if it does exist the only 
operation that is guaranteed to work is a cast from a pointer to an 
intptr_t and back again - all arithmetic on intptr_t is implementation 
defined.

Hello David,

I think adding an option which analogous to -fwrapv is a good candidate for
addressing the concern.
Well, I didn't know that arithmetic on intptr_t was implementation defined
- I thought the arithmetic on intptr_t is equivalent to the integer types.
Thanks for the point.

Juneyoung Lee

On Wed, Jan 16, 2019 at 9:40 AM David Chisnall <David.Chisnall at
cl.cam.ac.uk>
wrote:
> On 15/01/2019 16:26, Juneyoung Lee wrote:
> > If C programmer wants to get distance between two different objects,
> > s/he can use (intptr_t)p - (intptr_t)q instead of p - q.
>
> That's fine for new code, but unless you're volunteering to audit
the
> (roughly) 8 billion lines of open source C code and a corresponding
> (probably larger) amount of proprietary code, then making this
> assumption is going to break things.
>
>  From the relatively small survey that we did of C idioms as part of the
> CHERI project, I can tell you that this is very widespread.  This was
> something that we had to support (we considered only allowing pointer
> subtraction to yield a valid result when the operands referred to the
> same object and it broke pretty much everything we looked at).
>
> David
>
> P.S. If you want to talk about the standard with respect to intptr_t,
> you might want to reread what the standard actually says about it,
> specifically that a) it's optional, and b) if it does exist the only
> operation that is guaranteed to work is a cast from a pointer to an
> intptr_t and back again - all arithmetic on intptr_t is implementation
> defined.
>

-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/02eb2555/attachment.html>