| ... | ... | @@ -2930,6 +2930,24 @@ pub fn stackAlignment(target: *const Target) u16 { |
| 2930 | 2930 | return @divExact(target.ptrBitWidth(), 8); |
| 2931 | 2931 | } |
| 2932 | 2932 | |
| 2933 | pub const StackGrowth = enum { |
| 2934 | down, |
| 2935 | up, |
| 2936 | }; |
| 2937 | |
| 2938 | pub fn stackGrowth(target: *const Target) StackGrowth { |
| 2939 | // Strictly speaking, most architectures don't inherently define the stack growth direction; you |
| 2940 | // could quite easily argue that it is in fact a property of the ABI. However, that's just not |
| 2941 | // really how it plays out in the real world. And besides, we have no mechanism for indicating |
| 2942 | // a different stack growth ABI, nor a compelling use case for creating such a mechanism. |
| 2943 | return switch (target.cpu.arch) { |
| 2944 | .hppa, |
| 2945 | .hppa64, |
| 2946 | => .up, |
| 2947 | else => .down, |
| 2948 | }; |
| 2949 | } |
| 2950 | |
| 2933 | 2951 | /// Default signedness of `char` for the native C compiler for this target |
| 2934 | 2952 | /// Note that char signedness is implementation-defined and many compilers provide |
| 2935 | 2953 | /// an option to override the default signedness e.g. GCC's -funsigned-char / -fsigned-char |