| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html
llvm-svn: 187143
|
|
|
|
|
|
|
|
| |
r186899 and r187061 added a preferred way for some architectures not to get
intrinsic generation for math builtins. So the code changes in r185568 can
now be undone (the test remains).
llvm-svn: 187079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 64-bit PowerPC ELF ABI requires a struct that contains a single
vector member to be passed in a vector register as though the wrapping
struct were not present. Instead we were passing this as a byval
struct.
The same logic was already present for floating-point arguments, so
this patch just extends the logic to handle vector types. The new
test case verifies that clang coerces the parameter and annotates it
as inreg.
Thanks,
Bill
llvm-svn: 186993
|
|
|
|
| |
llvm-svn: 185792
|
|
|
|
| |
llvm-svn: 185715
|
|
|
|
|
|
|
|
|
|
|
| |
Without fmath-errno, Clang currently generates calls to @llvm.pow.* intrinsics
when it sees pow*(). This may not be suitable for all targets (for
example le32/PNaCl), so the attached patch adds a target hook that CodeGen
queries. The target can state its preference for having or not having the
intrinsic generated. Non-PNaCl behavior remains unchanged;
PNaCl-specific test added.
llvm-svn: 185568
|
|
|
|
|
|
|
|
| |
Empty structs are ignored for parameter passing purposes, but va_arg was
incrementing the pointer anyway which could lead to va_list getting out of
sync.
llvm-svn: 184605
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the Itanium ABI (3.1.1), types with non-trivial copy constructors
passed by value should be passed indirectly, with the caller creating a
temporary.
We got this mostly correct, but forgot that empty structs can have non-trivial
constructors too and passed them incorrectly. This simply reverses the order of
the check.
llvm-svn: 184603
|
|
|
|
| |
llvm-svn: 184166
|
|
|
|
| |
llvm-svn: 183837
|
|
|
|
|
|
|
|
| |
AVX vectors when AVX is turned on.
Fixes <rdar://problem/10513611>.
llvm-svn: 183813
|
|
|
|
| |
llvm-svn: 183720
|
|
|
|
| |
llvm-svn: 183590
|
|
|
|
| |
llvm-svn: 183583
|
|
|
|
|
|
|
|
| |
X86's 'y' inline assembly constraint represents an MMX register, this change
prevents Clang from hitting an assertion when passed an incompatible type to
deal with.
llvm-svn: 183467
|
|
|
|
|
|
|
|
|
|
|
|
| |
This could actually be implemented with the LLVM IR va_arg instruction,
but it doesn't seem to offer any advantages over accessing the va_list
pointer directly.
Using the va_list pointer directly makes it possible to perform type
coercion directly from the argument array, and the va_list updates are
exposed to the optimizers.
llvm-svn: 183292
|
|
|
|
|
|
| |
FAILIFMISMATCH linker command into the object file.
llvm-svn: 183178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The coercion type serves two purposes:
1. Pad structs to a multiple of 64 bits, so they are passed
'left-aligned' in registers.
2. Expose aligned floating point elements as first-level elements, so
the code generator knows to pass them in floating point registers.
We also compute the InReg flag which indicates that the struct contains
aligned 32-bit floats. This flag is used by the code generator to pick
the right registers.
llvm-svn: 182753
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- All integer arguments smaller than 64 bits are extended.
- Large structs are passed indirectly, not using 'byval'.
- Structs up to 32 bytes in size are returned in registers.
Some things are not implemented yet:
- EmitVAArg can be implemented in terms of the va_arg instruction.
- When structs are passed in registers, float members require special
handling because they are passed in the floating point registers.
- Structs are left-aligned when passed in registers. This may require
padding.
llvm-svn: 182745
|
|
|
|
|
|
| |
matches MSVC behavior, as well as allows us to properly link libraries such as the ones provided by the MSDN examples.
llvm-svn: 182647
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
llvm-svn: 181426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support. It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181211
|
|
|
|
|
|
|
|
|
| |
Also,
- abstract out the indirect/in memory/in registers decisions into the CGCXXABI
- fix handling of empty struct arguments for '-cxx-abi microsoft'
- add/fix tests
llvm-svn: 179681
|
|
|
|
|
|
| |
Patch by Stephen Lin!
llvm-svn: 179638
|
|
|
|
|
|
|
| |
Remove the custom lowering code dealing with it, disallow it in PNaclTargetInfo
and adjust tests accordingly.
llvm-svn: 179059
|
|
|
|
| |
llvm-svn: 178878
|
|
|
|
| |
llvm-svn: 178802
|
|
|
|
|
|
| |
functions for the NVPTX target.
llvm-svn: 178418
|
|
|
|
|
|
|
| |
intrinsics.
rdar://13213542
llvm-svn: 177911
|
|
|
|
|
|
|
|
|
| |
If this should not happen, we should have an assert.
If it should happen, we should have a test and remove the comment.
In no case should we have this self inconsistent code.
llvm-svn: 177399
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have filed http://llvm.org/bugs/show_bug.cgi?id=15538 against clang.
This code is safer anyway because "cast" assumes you really know that
it's okay to make the cast. In this case isa should not be false and
dyn_cast should not return null as far as I understand. But everything
else is valid so I did not want to revert my previous patch for attributes
mips16/nomips16 or use an llvm_unreachable here which would make a number
of our tests fail for mips.
llvm-svn: 177329
|
|
|
|
|
|
| |
in the LLVM assembly language output.
llvm-svn: 176971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.
Also, normalize the API for loading and storing complexes.
I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.
llvm-svn: 176656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
llvm-svn: 176286
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174055
|
|
|
|
|
|
| |
to pass floating point arguments to be passed in integer registers.
llvm-svn: 173375
|
|
|
|
|
|
| |
when adding a single attribute to the function.
llvm-svn: 173211
|
|
|
|
|
|
| |
Waiting for new llvm attribute code for the next step.
llvm-svn: 172626
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the 64-bit PowerPC ELF ABI.
The ABI requires that the real and imaginary parts of a complex argument
each occupy their own doubleword. Arguments smaller than 8 bytes are
right-adjusted within the doubleword.
Clang expects EmitVAARG() to return a pointer to a structure in which
the real and imaginary parts are packed adjacently in memory. To accomplish
this, we generate code to load the code appropriately from the varargs
location and pack the values into a temporary variable in the form Clang
expects, returning a pointer to that structure.
The test case demonstrates correct code generation for all "small" complex
types on PPC64: int, short, char, and float.
llvm-svn: 172438
|
|
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
|
|
|
| |
llvm-svn: 170722
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
|
|
| |
incompatibility with how complex values are returned. It is sufficient
to flag all complex types as direct rather than indirect.
A new test case is provided that checks correct IR generation for the
various supported flavors of _Complex.
llvm-svn: 170302
|
|
|
|
|
|
| |
in the near future.
llvm-svn: 169652
|
|
|
|
|
|
| |
in the triple.
llvm-svn: 169292
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
| |
llvm-svn: 168959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELF ABI.
Complex values are to be passed in registers as though the real and
imaginary parts were passed as separate parameters. Prior to this
patch, complex values were passed as byval aggregates. It turns out
that specifying getDirect() for all complex types when classifying the
argument type results in the desired behavior.
The new Clang test case verifies that the correct LLVM IR is generated
for caller and callee for each of the underlying types for _Complex.
llvm-svn: 168673
|
|
|
|
|
|
|
|
| |
patch makes Clang reflect this scheme.
Patch by Job Noorman!
llvm-svn: 168598
|