| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
There's no need to do this if the user doesn't call va_start. In the
future, we're going to have thunks that forward these register
parameters with musttail calls, and they won't need these spills for
handling va_start.
Most of the test suite changes are adding va_start calls to existing
tests to keep things working.
llvm-svn: 216294
|
| |
|
|
| |
llvm-svn: 216293
|
| |
|
|
| |
llvm-svn: 216292
|
| |
|
|
|
|
| |
r216288 (which was for plain-for loop condition variables).
llvm-svn: 216291
|
| |
|
|
| |
llvm-svn: 216289
|
| |
|
|
|
|
|
|
| |
for loops introduce two scopes - one for the outer loop variable and its
initialization, and another for the body of the loop, including any
variable declared inside the loop condition.
llvm-svn: 216288
|
| |
|
|
| |
llvm-svn: 216286
|
| |
|
|
|
|
|
|
| |
Mach-O files.
This adds the printing of the mach header. Load command printing will be next.
llvm-svn: 216285
|
| |
|
|
| |
llvm-svn: 216284
|
| |
|
|
|
|
|
|
| |
The situation it is warning about (see PR20725) is not very likely
to be a real problem, and it is unclear what action the user should take
if the warning does fire.
llvm-svn: 216283
|
| |
|
|
|
|
|
| |
+initialize is called on 'super' in its implementation.
rdar://16628028
llvm-svn: 216282
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch aims at fixing PR17239.
This bug happens because the /link (clang-cl.exe argument) is marked as
"consume all remaining arguments". However, when inside a response file,
/link should only consume all remaining arguments inside the response
file where it is located, not the entire command line after expansion.
The LLVM side of the patch will change the semantics of the
RemainingArgsClass kind to always consume only until the end of the
response file when the option originally came from a response file.
There are only two options in this class: dash dash (--) and /link.
This is the Clang side of the patch in http://reviews.llvm.org/D4899
Reviewered By: rafael, rnk
Differential Revision: http://reviews.llvm.org/D4900
Patch by Rafael Auler!
llvm-svn: 216281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains the LLVM side of the fix of PR17239.
This bug that happens because the /link (clang-cl.exe argument) is
marked as "consume all remaining arguments". However, when inside a
response file, /link should only consume all remaining arguments inside
the response file where it is located, not the entire command line after
expansion.
My patch will change the semantics of the RemainingArgsClass kind to
always consume only until the end of the response file when the option
originally came from a response file. There are only two options in this
class: dash dash (--) and /link.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4899
Patch by Rafael Auler!
llvm-svn: 216280
|
| |
|
|
| |
llvm-svn: 216279
|
| |
|
|
| |
llvm-svn: 216278
|
| |
|
|
|
|
|
|
|
| |
These pointers are really just offsets and they will always be
less than 16-bits. Using AssertZExt allows us to use computeKnownBits
to prove that these values are positive. We will use this information
in a later commit.
llvm-svn: 216277
|
| |
|
|
|
|
|
| |
DS_1A uses a single offset encoding, so offset1 wasn't being
encoded.
llvm-svn: 216276
|
| |
|
|
|
|
|
|
|
|
|
| |
Moreover, rework some patterns to actually check the emitted instructions
instead of matching unrelated string!
E.g.,
some of the "// CHECK: vmov" were matching stuff like ".globl
funcname_with_vmov" instead of actual instructions.
llvm-svn: 216275
|
| |
|
|
|
|
|
|
|
| |
instruction from ARMInstrInfo to ARMBaseInstrInfo.
That way, thumb mode can also benefit from the advanced copy optimization.
<rdar://problem/12702965>
llvm-svn: 216274
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Consider:
%add = add nuw i32 %a, -16777216
%and = and i32 %add, 255
Regardless of whether or not we demand the sign bit of %add, we cannot
replace -16777216 with 2130706432 without also removing 'nuw' from the
instruction.
llvm-svn: 216273
|
| |
|
|
|
|
|
|
|
| |
The ObjCDealloc checker is currently disabled because it was too aggressive, but this
is a good first step in getting it back to a useful state.
Patch by David Kilzer!
llvm-svn: 216272
|
| |
|
|
|
|
|
| |
to +initilize as this results in an extra call
to this method. rdar://16628028
llvm-svn: 216271
|
| |
|
|
|
|
|
|
|
|
| |
Fixes build for SPEC 2000 CPU. MSVC disables these aliases under /Za,
which enables stricter standards compliance. We don't currently have any
way to disable them.
Patch by Kevin Smith!
llvm-svn: 216270
|
| |
|
|
|
|
| |
We can preserve nsw during this transform if -C won't overflow.
llvm-svn: 216269
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5029
llvm-svn: 216268
|
| |
|
|
|
|
|
|
| |
'blah', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers."
This warning is basically useless because the "previous versions" being referred to is MSVC 2005 and earlier, and we obviously do not care about them. However, this warning isn't particularly chatty (I don't recall ever seeing it previously), and it has the opportunity to point out cases where the cv-qualifiers differ unintentionally (like this case), so I am leaving it enabled for now.
llvm-svn: 216267
|
| |
|
|
| |
llvm-svn: 216266
|
| |
|
|
| |
llvm-svn: 216265
|
| |
|
|
| |
llvm-svn: 216264
|
| |
|
|
|
|
| |
is not supported.
llvm-svn: 216263
|
| |
|
|
|
|
|
|
| |
calling convention if FP is 64-bit and +nooddspreg is used.
Differential Revision: http://reviews.llvm.org/D4981.diff
llvm-svn: 216262
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider:
%add = add nsw i32 %a, -16777216
%and = and i32 %add, 255
Regardless of whether or not we demand the sign bit of %add, we cannot
replace -16777216 with 2130706432 without also removing 'nsw' from the
instruction.
This fixes PR20377.
llvm-svn: 216261
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable that has regiser constraint "r" is not 64-bit.
General register operands are output using 64-bit "x" register names, regardless
of the size of the variable, unless the asm operand is prefixed with the "%w"
modifier. This surprises and confuses many users who aren't familiar with
aarch64 inline assembly rules.
With this commit, a note and fixit hint are printed which tell the users that
they need modifier "%w" in order to output a "w" register instead of an "x"
register.
<rdar://problem/12764785>
llvm-svn: 216260
|
| |
|
|
|
|
|
|
|
|
|
| |
The Itanium ABI will give out the same mangling number for two different
lambdas if their call operators have different types. The MS ABI cannot
do the same because it does not mangle the return type into it's
lambdas.
This fixes PR20719.
llvm-svn: 216259
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with binaries in the dyld shared cache (esp on iOS) where the file
address for the executable binary (maybe from memory, maybe from
an expanded copy of the dyld shared cache) is different from the
file address in the dSYM. In that case, ObjectFileMachO replaces
the file addresses from the original binary with the dSYM file
addresses (usually 0-based) -- lldb doesn't have a notion of two
file addresses for a given module so they need to agree.
There was a cache of file addresses over in the Symtab so I added
a method to the Module and the objects within to clear any file address
caches if they exist, and added an implementation in the Symtab
module to do that.
<rdar://problem/16929569>
llvm-svn: 216258
|
| |
|
|
| |
llvm-svn: 216257
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instructions.
In unreachable blocks it's legal to have instructions like "%x = op %x".
Such instuctions are not schedulable. Therefore the SLPVectorizer has to check for
unreachable blocks and ignore them.
Fixes bug 20646.
llvm-svn: 216256
|
| |
|
|
|
|
|
| |
We now use a std::vector instead of a DenseSet to store the list of
label checks so that we can iterate over it deterministically.
llvm-svn: 216255
|
| |
|
|
|
|
| |
dyn_cast -> dyn_cast_or_null to handle a null pointer.
llvm-svn: 216254
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation of AMD64 relocations was imcomplete
and wrong. On AMD64, we of course have to use AMD64
relocations instead of i386 ones. This patch fixes the
issue.
LLD is now able to link hello64.obj (created from
hello64.asm) against user32.lib and kernel32.lib to
create a Win64 binary.
llvm-svn: 216253
|
| |
|
|
|
|
| |
AddNewSourceBuffer using std::unique_ptr
llvm-svn: 216252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This refactoring introduces ClangToLLVMArgMapping class, which
encapsulates the information about the order in which function arguments listed
in CGFunctionInfo should be passed to actual LLVM IR function, such as:
1) positions of sret, if there is any
2) position of inalloca argument, if there is any
3) position of helper padding argument for each call argument
4) positions of regular argument (there can be many if it's expanded).
Simplify several related methods (ConstructAttributeList, EmitFunctionProlog
and EmitCall): now they don't have to maintain iterators over the list
of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities,
and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping.
This may increase the running time of EmitFunctionProlog, as we have to traverse
expandable arguments twice, but in further refactoring we will be able
to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to
ConstructAttributeList, thus avoiding traversing expandable argument there.
No functionality change.
Test Plan: regression test suite
Reviewers: majnemer, rnk
Reviewed By: rnk
Subscribers: cfe-commits, rjmccall, timurrrr
Differential Revision: http://reviews.llvm.org/D4938
llvm-svn: 216251
|
| |
|
|
|
|
|
|
|
| |
Given something like X01XX + X01XX, we know that the result must look
like X1XXX.
Adapted from a patch by Richard Smith, test-case written by me.
llvm-svn: 216250
|
| |
|
|
| |
llvm-svn: 216249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this case, we are creating an x86_fp80 slice for a union from C where
the padding bytes may contain real data. An x86_fp80 alloca is 16 bytes,
and that's just fine. We can't, however, use regular loads and stores to
access the slice, because the store size is only 10 bytes / 80 bits.
Instead, use memcpy and memset.
Fixes PR18726.
Reviewed By: chandlerc
Differential Revision: http://reviews.llvm.org/D5012
llvm-svn: 216248
|
| |
|
|
| |
llvm-svn: 216247
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This (mostly) reverts commit r216119.
Somewhere during the review Reid committed r214980 which fixed this
another way, and I neglected to check that the testcase still failed
before committing.
I've left test/CodeGen/X86/aligned-variadic.ll around in case it adds
extra coverage.
llvm-svn: 216246
|
| |
|
|
| |
llvm-svn: 216245
|
| |
|
|
|
|
|
| |
MSVC can't synthesize the explicit one. Instead it tries to emit a copy
ctor which would call the deleted copy ctor of unique_ptr.
llvm-svn: 216244
|
| |
|
|
|
|
|
| |
HostInfo et al changes from Zachary. Changes suggested by Zachary
- fixes the problems I was seeing.
llvm-svn: 216243
|