4 ms·

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct lay

> For example, for C and C++, sizeof is a constant expression, so you can't easily just do something like "defer evaluation to runtime". Plus ifdefs, struct layout, etc. What prevents things like sizeof(T) or alignof(T) from being representable in the LLVM IR in a form that says, "defer to final translation" (to the target architecture)? Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? It would seem useful for me for LLVM IR to retain some platform-dependent types like size_t or intptr_t (deferring until final translation from bitcode to machine code), but maybe that would inhibit certain optimizations.

CJefferson 11y ago
The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.
- tomjakubowski 11y ago
  > The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value. I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->LLVM stage of compilation. What is the compile time part of C do you mean? sizeof(T) is evaluated at compile time of course, but it would still produce pseudocode like: if (4 < 16) { // sizeof(T) replaced with 4 // do something } else { // do something else } Of course, an optimizer would likely constant-fold that conditional expression to remove the branch entirely, but I'm having a difficult time seeing how one could perform different behavior at compile time with sizeof(T) in C.
  - deleted 11y ago
    [deleted]
  - DannyBee 11y ago
    #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) https://scaryreasoner.wordpress.com/2009/02/28/checking-sizeof-at-compile-time/ https://scaryreasoner.wordpress.com/2009/02/28/checking-size... There are many ways to make it perform different behavior at compile time (though admittedly, most are abuse). The above should compile error, but if you push sizeof evaluation, will not.
    - TheLoneWolfling 11y ago
      Better form, for certain definitions of better (works in global scope): #define BUILD_BUG_ON(condition) extern int build_bug_on[!!(condition)-1]
- DannyBee 11y ago
  It's worse than this. For example, you'd never be able to issue diagnostics about constexpr's. You'd also not be able to layout structs, etc.
DannyBee 11y ago
"Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? " In LLVM world, Clang is performing most of the ABI lowering. For C and C++, the answer is "yes", and "it must happen this way", because struct layout/etc will depend on it. Not to mention what you want is at some level, impossible in the LLVM IR. LLVM types are not C/C++ types. This leaves you with no type system capable to do the kind of thing you want to do :)

CJefferson 11y ago

The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value.

tomjakubowski 11y ago
> The short version is, that just isn't possible. Too many things would be unknown, and it is easy in both C and C++ to, at compile time, check the sizeof(size_t) and perform totally different behaviour depending on the value. I can see an issue with template instantiation in C++: for example, if a template uses SFINAE to specialize a template for types of certain sizes, that needs to be evaluated purely at the C++->LLVM stage of compilation. What is the compile time part of C do you mean? sizeof(T) is evaluated at compile time of course, but it would still produce pseudocode like: if (4 < 16) { // sizeof(T) replaced with 4 // do something } else { // do something else } Of course, an optimizer would likely constant-fold that conditional expression to remove the branch entirely, but I'm having a difficult time seeing how one could perform different behavior at compile time with sizeof(T) in C.
- deleted 11y ago
  [deleted]
- DannyBee 11y ago
  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)])) https://scaryreasoner.wordpress.com/2009/02/28/checking-sizeof-at-compile-time/ https://scaryreasoner.wordpress.com/2009/02/28/checking-size... There are many ways to make it perform different behavior at compile time (though admittedly, most are abuse). The above should compile error, but if you push sizeof evaluation, will not.
  - TheLoneWolfling 11y ago
    Better form, for certain definitions of better (works in global scope): #define BUILD_BUG_ON(condition) extern int build_bug_on[!!(condition)-1]
DannyBee 11y ago
It's worse than this. For example, you'd never be able to issue diagnostics about constexpr's. You'd also not be able to layout structs, etc.

DannyBee 11y ago

"Does substitution of platform-dependent types, for example, i64 for size_t on x86_64, happen prior to generating the LLVM IR? " In LLVM world, Clang is performing most of the ABI lowering. For C and C++, the answer is "yes", and "it must happen this way", because struct layout/etc will depend on it. Not to mention what you want is at some level, impossible in the LLVM IR. LLVM types are not C/C++ types. This leaves you with no type system capable to do the kind of thing you want to do :)