llvm dev - Jun 2021 - TBAA

> I would think that in a language like C, the role of the optimizer
> should be to do optimizations that are difficult or impossible or
> time consuming for the programmer.
That's a philosphical question.  Keep in mind that very few
programmers nowadays, even in C, have a good idea of the underlying
machine model (or even the fact that there *is* such a model), so they
don't really even know what to do.  Also, think of macro expansion and
such.  And maintenance costs over time if you add all of the
"clutter".  I would argue against that view.
> My concern is that TBAA has a trade-off in terms of the complexity of the
> language for the programmer
I don't understand.  TBAA implements the rules of the programming language
with respect to aliasing.  It doesn't change the language in any way, so 
I don't see how it can increase the complexity for the programmer.

Perhaps you're arguing that anti-aliasing rules in languages aren't
worth the complexity, but that's a different issue and one that language
design groups look at, not compiler writers.

On Fri, Jun 18, 2021 at 10:13 AM Richard Kenner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > I would think that in a language like C, the role of the optimizer
> > should be to do optimizations that are difficult or impossible or
> > time consuming for the programmer.
>
> That's a philosphical question.  Keep in mind that very few
> programmers nowadays, even in C, have a good idea of the underlying
> machine model (or even the fact that there *is* such a model), so they
> don't really even know what to do.  Also, think of macro expansion and
> such.  And maintenance costs over time if you add all of the
> "clutter".  I would argue against that view.
>
> > My concern is that TBAA has a trade-off in terms of the complexity of
the
> > language for the programmer
>
> I don't understand.  TBAA implements the rules of the programming
language
> with respect to aliasing.  It doesn't change the language in any way,
so
> I don't see how it can increase the complexity for the programmer.
>
> Perhaps you're arguing that anti-aliasing rules in languages aren't
> worth the complexity, but that's a different issue and one that
language
> design groups look at, not compiler writers.
>
There's a lot of overlap, and it's probably good for language design
groups
to be talking to compiler writers (as in this thread) to understand what
really matters in practice - if the answer was "there aren't
significant
benefits to using TBAA" then maybe that'd inform language design groups
to
remove such requirements from their specifications, etc. I expect that's
where Victor is coming at this from - to understand/gather implementation
experience to inform language design.

Or potentially to inform compiler implementations - violating TBAA is UB,
so it's valid for an implementation to define that behavior (eg: could
change the default to be -fno-strict-aliasing).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210618/af9945a4/attachment.html>