7 Commits

Author SHA1 Message Date
Timm Baeder
dc6e4805a0
[clang][bytecode] Cast fixed-point cmp result to int if necessary (#110469)
This is the case in C.
2024-09-30 12:01:10 +02:00
Mariya Podchishchaeva
9ad72df55c
[clang] Use different memory layout type for _BitInt(N) in LLVM IR (#91364)
There are two problems with _BitInt prior to this patch:
1. For at least some values of N, we cannot use LLVM's iN for the type
of struct elements, array elements, allocas, global variables, and so
on, because the LLVM layout for that type does not match the high-level
layout of _BitInt(N).
Example: Currently for i128:128 targets correct implementation is
possible either for __int128 or for _BitInt(129+) with lowering to iN,
but not both, since we have now correct implementation of __int128 in
place after a21abc7.
When this happens, opaque [M x i8] types used, where M =
sizeof(_BitInt(N)).
2. LLVM doesn't guarantee any particular extension behavior for integer
types that aren't a multiple of 8. For this reason, all _BitInt types
are now have in-memory representation that is a whole number of bytes.
I.e. for example _BitInt(17) now will have memory layout type i32.

This patch also introduces concept of load/store type and adds an API to
CodeGenTypes that returns the IR type that should be used for load and
store operations. This is particularly useful for the case when a
_BitInt ends up having array of bytes as memory layout type. For
_BitInt(N), let M = sizeof(_BitInt(N)), and let BITS = M * 8. Loads and
stores of iM would both (1) produce far better code from the backends
and (2) be far more optimizable by IR passes than loads and stores of [M
x i8].

Fixes https://github.com/llvm/llvm-project/issues/85139
Fixes https://github.com/llvm/llvm-project/issues/83419

---------

Co-authored-by: John McCall <rjmccall@gmail.com>
2024-07-15 09:40:39 +02:00
Fangrui Song
c5de4dd1ea [test] %clang_cc1 -emit-llvm: remove redundant -S
And replace -emit-llvm -o - with -emit-llvm-only
2024-05-04 17:00:29 -07:00
Nikita Popov
9466b49171 [Clang] Convert various tests to opaque pointers (NFC)
These were all tests where no manual fixup was required.
2022-12-12 17:11:46 +01:00
Nikita Popov
532dc62b90 [OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)
This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

Differential Revision: https://reviews.llvm.org/D123115
2022-04-07 12:09:47 +02:00
Aaron Ballman
7de7161304 Use functions with prototypes when appropriate; NFC
A significant number of our tests in C accidentally use functions
without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the sixth batch of tests being updated (there are a significant
number of other tests left to be updated).
2022-02-09 17:16:10 -05:00
Leonard Chan
ce1d4f1bec [Fixed Point Arithmetic] Fixed Point Comparisons
This patch implements fixed point comparisons with other fixed point types and
integers. This also provides constant expression evaluation for them.

Differential Revision: https://reviews.llvm.org/D57219

llvm-svn: 354621
2019-02-21 20:50:09 +00:00