[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 11 12:24:47 PDT 2019
I agree that readability, maintainability, and ability to debug/find issues
I haven't found myself in a situation where unsigned was helping my
readability: on the opposite actually I am always wondering where is the
expecting wrap-around behavior and that is one more thing I have to keep in
mind when I read code that manipulate unsigned. So YMMV but using unsigned
*increases* my mental load when reading code.
On Tue, Jun 11, 2019 at 12:00 PM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev