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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
