Commit Graph

13 Commits

Author SHA1 Message Date
Tim Northover c46827c7ed LLVM IR: Generate new-style byval-with-Type from Clang
LLVM IR recently added a Type parameter to the byval Attribute, so that
when pointers become opaque and no longer have an element type the
information will still be present in IR.

For now the Type parameter is optional (which is why Clang didn't need
this change at the time), but it will become mandatory soon.

llvm-svn: 362652
2019-06-05 21:12:14 +00:00
Pengfei Wang 48387ec187 Revert "[X86] Fix i386 struct and union parameter alignment"
This reverts commit d61cb749f4 (SVN:
361934).

According to James suggestion, revert this change. Please ref:
https://reviews.llvm.org/D60748

llvm-svn: 362186
2019-05-31 01:50:07 +00:00
Pengfei Wang d61cb749f4 [X86] Fix i386 struct and union parameter alignment
According to i386 System V ABI 2.1: Structures and unions assume the
alignment of their most strictly aligned component. But current
implementation always takes them as 4-byte aligned which will result
in incorrect code, e.g:

 1 #include <immintrin.h>
 2 typedef union {
 3         int d[4];
 4         __m128 m;
 5 } M128;
 6 extern void foo(int, ...);
 7 void test(void)
 8 {
 9   M128 a;
10   foo(1, a);
11   foo(1, a.m);
12 }

The first call (line 10) takes the second arg as 4-byte aligned while
the second call (line 11) takes the second arg as 16-byte aligned.
There is oxymoron for the alignment of the 2 calls because they should
be the same.

This patch fixes the bug by following i386 System V ABI and apply it to
Linux only since other System V OS (e.g Darwin, PS4 and FreeBSD) don't
want to spend any effort dealing with the ramifications of ABI breaks
at present.

Patch by Wei Xiao (wxiao3)

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

llvm-svn: 361934
2019-05-29 08:42:35 +00:00
David Blaikie d6c88ece21 [opaque pointer types] Explicit non-pointer type for call expressions
(migration for recent LLVM change to textual IR for calls)

llvm-svn: 235147
2015-04-16 23:25:00 +00:00
Stephen Lin 4362261b00 CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.
llvm-svn: 188447
2013-08-15 06:47:53 +00:00
Chad Rosier 651c1839ee IR-gen should not generate an MMX types unless the code is explicitly using MMX
intrinsics.
rdar://13213542

llvm-svn: 177911
2013-03-25 21:00:27 +00:00
Bill Wendling 48939ced20 Update testcases due to Attribute sorting improvements.
llvm-svn: 175253
2013-02-15 05:25:49 +00:00
Bill Wendling 85ab57ac5d Update the tests.
This update coincides with r174110. That change ordered the attributes
alphabetically.

llvm-svn: 174111
2013-01-31 23:17:12 +00:00
Eli Friedman 3346582bca Change -mno-mmx to be more compatible with gcc. Specifically, -mno-mmx should not imply -mno-sse.
Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.

clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.

<rdar://problem/9694837>

llvm-svn: 134770
2011-07-08 23:31:17 +00:00
Chris Lattner e76b95ae15 make the x86-32 backend specify a byval alignment, even when the
code generator will do it.  With this patch, clang compiles the example
in PR9794 to not have an alloca temporary.

llvm-svn: 131881
2011-05-22 23:35:00 +00:00
Bill Wendling 5cd41c4b13 Reapply r116684 with fixes. The test cases needed to be updated.
llvm-svn: 116696
2010-10-18 03:41:31 +00:00
Daniel Dunbar dd38fbc7fb IRgen/ABI/x86-32: Realign indirect arguments when the ABI requires us to pass
them with a smaller alignment than the rest of codegen expects.

llvm-svn: 114115
2010-09-16 20:42:06 +00:00
Daniel Dunbar 8a6c91ff76 IRgen/x86_32/Linux: Linux seems to align all stack objects to 4 bytes, unlike
Darwin. Checked vs the handiest Linux llvm-gcc I had around, someone on Linux is
welcome to investigate more.

llvm-svn: 114112
2010-09-16 20:41:56 +00:00