[llvm-dev] TBAA

[Victor Yodaiken via llvm-dev]

On Fri, Jun 18, 2021 at 3:47 PM Richard Kenner <kenner at adacore.com> wrote:

> > I am working on it. So far I cannot find cases other than the obvious
> > loop hoisting ones - which C programmers can do themselves.
>
> Again, the fact that they *can* doesn't at all mean they know they should.
>

It is easy to write bad code in C, for sure. Perhaps I have a minority
opinion, but I think programmers who don't get the memory model or don't
want to think about it have better alternatives than C. I really like C,
but not for all purposes. There are good reasons for languages like Java,
Go, Dart, etc.  where much of the low level memory stuff is left to the
compiler. But there is a good reason for C, especially
when we need to work with the representations of values.

reasonable aliasing rules (which, by the way, will result in cleaner
> code), you won't have to manually create new variables in order for your
> program to be more efficient: you can write it in whatever way is easiest
> for you".
>

The flip side is that many things that are common in C practice, even
essential for writing C library functions and operating systems, are
(silently!) disabled
or made shaky by C alias rules - which is why Linux, for example, uses
fno_strict_aliasing and musl relies on may_alias.  The canonical examples
of problems are memcpy, allocators like malloc/free, and network packet
classifiers.  Or see https://blog.regehr.org/archives/1307

The original C aliasing rules were kind of slipped into the standard just a
year or so after a pretty stiff dispute between the ANSI committee and
Dennis Ritchie about aliasing, and, quite obviously, they were not
completely thought out (e.g. the necessity of a hurried addition of the
character pointer exception).  Anyways, my goal right now  is to understand
the tradeoffs better.
vy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210618/2e63d74c/attachment.html>