[PATCH] D81285: [builtins] Change si_int to int in some helper declarations
Anatoly Trosinenko via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jun 9 08:46:14 PDT 2020
atrosinenko added a comment.
In D81285#2082394 <https://reviews.llvm.org/D81285#2082394>, @aykevl wrote:
> I'm not sure whether `native_int` is any clearer than just `int`. I'm afraid it only introduces more complexity ("What's `native_int`? Oh, it's just `int`").
I'm not particularly insisting on the `native_int`, `default_int` or something similar. The decision to use some custom `typedef` is definitely an RFC here. My initial point was it explicitly notifies the reader "this type is not because I had not a better idea, it was specified intentionally as `int`".
> Perhaps a controversial idea: what about changing to use stdint.h types?
> `si_int` -> `int32_t`
> `su_int` -> `uint32_t`
> `di_int` -> `int64_t`
> etc
> These types are clearly defined and immediately recognizable.
I definitely support using the traditional integer types from `stdint.h` instead of some locally defined and not generally known ones.
> The meaning is, as far as I can see, exactly the same (`si_int` etc seems to be a leftover from GCC internal naming conventions, such as `SImode`).
... I would just recheck (myself) that these three modes are identical "by definition" and replace them with `sed` :)
> Also note that the libgcc documentation does not always reflect the real world. For example, `__divmodsi4` on AVR libgcc has a very different signature: it returns both the division result and the remainder in registers.
Do you mean some special calling convention not used outside the `libgcc`/`clang_rt`? MSP430 has one as well. And I still have to decide how to express for //some of// generic C implementations that they should use that special calling convention on MSP430 without cluttering the sources with `O(target count)` complexity. :) Meanwhile, some hacks do exist for ARM target already.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D81285/new/
https://reviews.llvm.org/D81285
More information about the cfe-commits
mailing list