[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."

[Zachary Turner via llvm-dev]

I would argue that unless you've benchmarked a piece of code found this to
be a problem, then writing code with the express purpose of having it be
more optimizable at the expense of readability and ease of understanding is
a classic example of premature optimization.  And if you have, then you can
used signed integers in that specific piece of code, and leave a comment
about why it should not be changed.

On Tue, Jun 11, 2019 at 9:59 AM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> James Henderson via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > Maybe it's just because I work in code around the binary file formats
> > almost exclusively, but unsigned (or more often uint64_t) is FAR more
> > common than int everywhere I go. I don't have time right now to read
> > up on the different links you provided, and I expect this is covered
> > in them, but it also seems odd to me to use int in a loop when
> > indexing in a container (something that can't always be avoided),
> > given the types of size() etc.
>
> The reason to use int as an index in loops is for its algebraic
> properties, which allows some optimizations (vectorization, for
> example), where unsigned would cause problems.
>
> Basically, the optimizer can assume overflow is undefined behavior and
> optimize accordingly.
>
> +10000 for preferring signed unless there's a good reason for unsigned.
>
>                     -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/0a34cc3a/attachment.html>