Age | Commit message (Collapse) | Author |
|
Also, fix the way we override DefaultABIInfo methods, since
classifyArgumentType and classifyReturnType are not actually virtual.
Also, DefaultABIInfo does the right thing for floating-point types,
so we don't need to special-case them.
|
|
For us, staying in sync with upstream on issues related to the memory model
is more important. None of clang, gcc, nor icc appear to offer these features.
If such features are desirable, they should ideally be implemented in upstream
clang, in a target-independent way, since this issue would affect users of all
platforms which support threads, not just PNaCl or Emscripten.
|
|
Notable changes from le32-unknown-nacl so far include:
- Set i32 as the legal integer set, to help the optimizer avoid creating
needlessly inefficient code for asm.js.
- We can use llvm.pow.
- Don't predefine __ELF__ or __pnacl__ so that we don't need to undefine
them later.
- Do predefine asm.js and Emscripten macros, so that we don't need to
define them later.
- Don't provide __has_feature(pnacl).
|
|
This is a companion patch to:
https://codereview.chromium.org/22240002/
https://codereview.chromium.org/22474008/
and deals with the Clang-side of things.
The above patch will handle the fallouts of this Clang patch, including
some changes to un-duplicate work that RewriteAsmDirectives.cpp
does. The goal of this patch is to force some extra ordering on
non-atomics for le32 which LLVM doesn't necessarily provide.
R=eliben@chromium.org
TEST= ninja check-all
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3475
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3611
Review URL: https://codereview.chromium.org/22294002
|
|
Conflicts:
lib/CodeGen/ItaniumCXXABI.cpp
|
|
|
|
SVN log from upstream clang:
r185568 | eliben | 2013-07-03 12:19:12 -0700 (Wed, 03 Jul 2013)
Add target hook CodeGen queries when generating builtin pow*.
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.
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3513
R=dschuff@chromium.org
Review URL: https://codereview.chromium.org/18953003
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179681 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by Stephen Lin!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179638 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Remove the custom lowering code dealing with it, disallow it in PNaclTargetInfo
and adjust tests accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178878 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178802 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functions for the NVPTX target.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178418 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
intrinsics.
rdar://13213542
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177911 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177399 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the LLVM assembly language output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176971 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174055 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to pass floating point arguments to be passed in integer registers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173375 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when adding a single attribute to the function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173211 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Waiting for new llvm attribute code for the next step.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172626 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172438 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170722 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
which is wrong here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170721 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single attribute in the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170302 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169652 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
in the triple.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169292 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168959 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168673 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
patch makes Clang reflect this scheme.
Patch by Job Noorman!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168598 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167476 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
disabling byval, we set realign to true.
It will perform an aligned alloca, and call memcpy to copy the byval
argument to the local variable.
Change the size threshold back to 64 bytes.
rdar://12596507
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the type alignment of the byval argument. This patch will disable byval in this case,
it also increases the size threshold for turning on byval.
A backend fix will be attempted.
rdar://12596507
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167416 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
zero-extended to 64 bits. This information is currently provided to
the back end by setting "signext" or "zeroext" attributes. However,
this is done only for integer types *smaller* than i32, not for i32
itself. This causes clang to generate code violating the ABI, which
results in a failure of the tramp3d-v4 test case (due to calling a
system library routine without ABI-required extension).
This patch implements custom versions of classifyArgumentType and
classifyReturnType for PPC64_SVR4_ABIInfo, which are the same as the
default versions except that they also classify "int" and "unsigned int"
as types needing extending. This fixed tramp3d-v4 on PowerPC64.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
According to the spec, we can backfill VFP registers that were skipped due
to alignment constraints.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If HA can only partially fit into VFP registers, we add padding to make sure
HA will be on stack and later VFP CPRCs will be on stack as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167058 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
varargs parameter passing.
A strict reading of the ABI indicates that any argument with alignment greater
than 8 may require skipping doublewords in the parameter save area to align
the argument, and hence require skipping GPRs. In practice, this is not done
by GCC. The alignment restriction is used for internal alignment of a
structure, but a structure with 16-byte alignment, for example, is not
itself 16-byte aligned in the parameter save area. Although this is messy,
it has become the de facto standard used in building existing libraries.
My initial varargs support followed the ABI language, but not the de facto
standard. Running the GCC compatibility test suite exposed this issue, and
indeed showed that LLVM didn't pass parameters self-consistently with my
original logic. Removing the additional alignment logic allows the affected
tests to now pass.
I modified the ppc64-varargs-struct.c test case to remove the existing test
for generation of alignment code, which is no longer appropriate.
Built and tested on powerpc64-unknown-linux-gnu with no new regressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variables when using a gnueabihf or aapcs-vfp target.
Tested by me and Wei-Ren Chen.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166679 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the x86_fastcallcc calling convention.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166538 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166537 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
regression.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166377 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
constructors.
When I first moved regparm support to TargetInfo.cpp I tried to isolate it
in classifyArgumentTypeWithReg, but it is actually a lot easier to flip the
code around and check for regparm at the end of the decision tree.
Without this refactoring classifyArgumentTypeWithReg would have to duplicate
the logic about when to use non-byval indirect arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166266 91177308-0d34-0410-b5e6-96231b3b80d8
|