builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@138985 91177308-0d34-0410-b5e6-96231b3b80d8
A homogeneous aggregate is an aggregate data structure where after flattening
any nesting there are 1 to 4 elements of the same base type that is either a
float, double, or Neon vector. All Neon vectors of the same size, either 64
or 128 bits, are treated as equivalent for this purpose. When using the
AAPCS-VFP ABI, check for homogeneous aggregates and pass them as arguments by
expanding them into a sequence of their base types. This requires extending
the existing support for expanded arguments to handle not only structs, but
also constant arrays and complex types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136767 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 67d097e123.
We found a miscompile with ARM byval, which is still being investigated.
In the meantime, this works around the problem by disabling ARM byval.
Conflicts:
lib/CodeGen/TargetInfo.cpp
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136662 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134770 91177308-0d34-0410-b5e6-96231b3b80d8
The fixed implementation is compatible with the implementation both gcc and llvm-gcc use.
rdar://9686430 . (This is the issue that was reported in the thread "[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable".)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@134059 91177308-0d34-0410-b5e6-96231b3b80d8
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133103 91177308-0d34-0410-b5e6-96231b3b80d8
code generator will do it. With this patch, clang compiles the example
in PR9794 to not have an alloca temporary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131881 91177308-0d34-0410-b5e6-96231b3b80d8
generator will give it something sufficient. This is important because
the mid-level optimizer doesn't know what alignment is required otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131879 91177308-0d34-0410-b5e6-96231b3b80d8
of which break strict compatibility with previous compilers. Implement
one of them and then immediately opt out on Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129899 91177308-0d34-0410-b5e6-96231b3b80d8
AAPCS+VFP), similar to fastcall / stdcall / whatevercall seen on x86.
In particular, all library functions should always be AAPCS regardless of floating point ABI used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129534 91177308-0d34-0410-b5e6-96231b3b80d8
clobber with the 'y' constraint. Otherwise, we get the wrong return type and an
assert, because it created a '<1 x i64>' vector type instead of the x86_mmx
type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127185 91177308-0d34-0410-b5e6-96231b3b80d8
Douglas Gregor
John McCall
Akira Hatanaka
Bob Wilson
Rafael Espindola
Chris Lattner
Joerg Sonnenberger
Bruno Cardoso Lopes
Jay Foad
Eli Friedman
NAKAMURA Takumi
Roman Divacky
Argyrios Kyrtzidis
Stuart Hastings
Eric Christopher
Justin Holewinski
Daniel Dunbar
Anton Korobeynikov
Sandeep Patel
Bill Wendling
Tilmann Scheller