Thanks. I am working on it. So far I cannot find cases other than the
obvious loop hoisting ones - which C programmers can do themselves.
vy
On Fri, Jun 18, 2021 at 1:13 PM David Blaikie <dblaikie at gmail.com>
wrote:
> 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/313dd152/attachment.html>