| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 141193
|
|
|
|
| |
llvm-svn: 140407
|
|
|
|
| |
llvm-svn: 140367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
if the definition has a non-variadic prototype with compatible
parameters. Therefore, the default rule for such calls must be to
use a non-variadic convention. Achieve this by casting the callee to
the function type with which it is required to be compatible, unless
the target specifically opts out and insists that unprototyped calls
should use the variadic rules. The only case of that I'm aware of is
the x86-64 convention, which passes arguments the same way in both
cases but also sets a small amount of extra information; here we seek
to maintain compatibility with GCC, which does set this when calling
an unprototyped function.
Addresses PR10810 and PR10713.
llvm-svn: 140241
|
|
|
|
|
|
| |
UnwindException structure is 32 for mips64.
llvm-svn: 140165
|
|
|
|
| |
llvm-svn: 140161
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 138985
|
|
|
|
|
|
|
| |
apparent general rule. Just special-case it as appropriate.
PR10789.
llvm-svn: 138792
|
|
|
|
| |
llvm-svn: 137420
|
|
|
|
| |
llvm-svn: 137411
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 136767
|
|
|
|
|
|
| |
Patch by Jim (Ningjie) Chen.
llvm-svn: 136734
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 67d097e1232b7d66f58989c16a45b8a11721f76e.
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
llvm-svn: 136662
|
|
|
|
|
|
|
|
|
|
| |
without bailing out when va_arg is an aggregate expression. However,
alignment checking needs to be added in isSafeToEliminateVarargsCast in
InstCombineCalls.cpp in order to produce correct mips code (see link below).
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/042047.html
llvm-svn: 136647
|
|
|
|
| |
llvm-svn: 136630
|
|
|
|
|
|
|
|
| |
LLVM.h imports
them into the clang namespace.
llvm-svn: 135852
|
|
|
|
| |
llvm-svn: 135370
|
|
|
|
| |
llvm-svn: 135285
|
|
|
|
|
|
| |
failures.
llvm-svn: 135091
|
|
|
|
| |
llvm-svn: 135004
|
|
|
|
| |
llvm-svn: 134952
|
|
|
|
|
|
| |
passing.
llvm-svn: 134951
|
|
|
|
|
|
| |
which is: { <4 x float>, <4 x float> } should continue to go through memory.
llvm-svn: 134946
|
|
|
|
|
|
| |
add one more testcase.
llvm-svn: 134934
|
|
|
|
| |
llvm-svn: 134893
|
|
|
|
| |
llvm-svn: 134831
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 134765
|
|
|
|
| |
llvm-svn: 134754
|
|
|
|
|
|
| |
The start of some work on getting -mno-mmx working the way we want it to.
llvm-svn: 134300
|
|
|
|
|
|
|
|
|
|
| |
address takes up an integer register (if one is available). Make sure the x86-64 ABI implementation takes that into account properly.
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".)
llvm-svn: 134059
|
|
|
|
| |
llvm-svn: 133501
|
|
|
|
| |
llvm-svn: 133365
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 133103
|
|
|
|
| |
llvm-svn: 132443
|
|
|
|
|
|
|
| |
code generator will do it. With this patch, clang compiles the example
in PR9794 to not have an alloca temporary.
llvm-svn: 131881
|
|
|
|
|
|
|
| |
generator will give it something sufficient. This is important because
the mid-level optimizer doesn't know what alignment is required otherwise.
llvm-svn: 131879
|
|
|
|
| |
llvm-svn: 131558
|
|
|
|
| |
llvm-svn: 131450
|
|
|
|
| |
llvm-svn: 131447
|
|
|
|
|
|
| |
regression in mason. rdar://problem/7662569
llvm-svn: 130444
|
|
|
|
| |
llvm-svn: 130423
|
|
|
|
|
|
| |
rdar://problem/7662569
llvm-svn: 130417
|
|
|
|
| |
llvm-svn: 130312
|
|
|
|
| |
llvm-svn: 130179
|
|
|
|
| |
llvm-svn: 130176
|
|
|
|
| |
llvm-svn: 129987
|
|
|
|
|
|
|
| |
of which break strict compatibility with previous compilers. Implement
one of them and then immediately opt out on Darwin.
llvm-svn: 129899
|
|
|
|
| |
llvm-svn: 129823
|
|
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|