llvm dev - Jun 2021 - TBAA

Exactly.  The C Standards committee has justified complex rules for
programmers and compiler writers ( which seem to often cause programmers to
yell at compiler writers) on the basis of optimization gains - but without
much documentation. I am looking for information on whether those are
significant enough to justify the tradeoff.

thanks
vy


On Fri, Jun 18, 2021 at 1:03 PM David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> 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/7a4a358a/attachment.html>

I don't have great data, but if you have any relevant benchmarks of your
own you can try them -f{no-}strict-aliasing to compare their performance

On Fri, Jun 18, 2021 at 11:11 AM Victor Yodaiken <victor.yodaiken at
gmail.com>
wrote:
> Exactly.  The C Standards committee has justified complex rules for
> programmers and compiler writers ( which seem to often cause programmers to
> yell at compiler writers) on the basis of optimization gains - but without
> much documentation. I am looking for information on whether those are
> significant enough to justify the tradeoff.
>
> thanks
> vy
>
>
> On Fri, Jun 18, 2021 at 1:03 PM David Blaikie <dblaikie at gmail.com>
wrote:
>
>>
>>
>> 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/62dcae29/attachment.html>