Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Wed, 11 Sep 2024 10:38:24 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 75
Message-ID: <2024Sep11.123824@mips.complang.tuwien.ac.at>
References: <vaqgtl$3526$1@dont-email.me> <memo.20240830090549.19028u@jgd.cix.co.uk> <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com> <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z>
Injection-Date: Wed, 11 Sep 2024 13:16:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b85cbd8c0f8da78fd972df370514ef55";
	logging-data="3765935"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+UfJpdugyEBCm80SnkZvMB"
Cancel-Lock: sha1:mZbhtyxBpkpxntCAm7CrzfA5JrE=
X-newsreader: xrn 10.11
Bytes: 4282

Josh Vanderhoof <x@y.z> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> George Neuner <gneuner2@comcast.net> writes:
>>>On Sun, 08 Sep 2024 15:36:39 GMT, anton@mips.complang.tuwien.ac.at
>>>(Anton Ertl) wrote:
>>>>1) At first I thought that yes, one could just check whether there is
>>>>an overlap of the memory areas.  But then I remembered that you cannot
>>>>write such a check in standard C without (in the general case)
>>>>exercising undefined behaviour; and then the compiler could eliminate
>>>>the check or do something else that's unexpected.  Do you have such a
>>>>check in mind that does not exercise undefined behaviour in the
>>>>general case?
....
>It is legal to test for equality between pointers to different objects
>so you could test for overlap by testing against every element in the
>array.  It seems like it should be possible for the compiler to figure
>out what's happening and optimize those tests away, but unfortunately
>no compiler I tested did it.

That would be an interesting result of the ATUBDNH lunacy: programmers
would see themselves forced to write workarounds such as the one you
suggest (with terrible performance when not optimized), and then C
compiler maintainers would see themselves forced to optimize this kind
of code.  The end result would be that both parties have to put in
more effort to eventually get the same result as if ordered comparison
between different objects had been defined from the start.

For now, the ATUBDNH advocates tell programmers that they have to work
around the lack of definition, but there is usually no optimization
for that.

One case where things work somewhat along the lines you suggest is
unaligned accesses.  Traditionally, if knowing that the hardware
supports unaligned accesses, for a 16-bit load one would write:

int16_t foo1(int16_t *p)
{
  return *p;
}

If one does not know that the hardware supports unaligned accesses,
the traditional way to perform such an access (little-endian) is
something like:

int16_t foo2(int16_t *p)
{
  unsignedchar *q = p;
  return (int16_t)(q[0] + (q[1]>>8));
}

Now, several years ago, somebody told me that the proper way is as
follows:

int16_t foo3(int16_t *p)
{
   int16_t v;
   memcpy(&v,p,2);
   return v;
}

That way looked horribly inefficient to me, with v having to reside in
memory instead of in a register and then the expensive function call,
and all the decisions that memcpy() has to take depending on the
length argument.  But gcc optimizes this idiom into an unaligned load
rather than taking all the steps that I expected (however, I have seen
cases where the code produced on hardware that supports unaligned
accesses is worse than that for foo1()).  Of course, if you also want
to support less sophisticated compilers, this idiom may be really slow
on those, although not quite as expensive as your containment check.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>