| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
This change removes libclang_rt.profile-pic-<arch>.a version of
profile runtime. Instead, it's sufficient to always build
libclang_rt.profile-<arch>.a with -fPIC, as it can be linked into
both executables and shared objects.
llvm-svn: 221952
|
| |
|
|
|
|
|
|
|
|
| |
Hide the fact that `MDString`'s string is stored in `Value::Name` --
that's going to change soon. Update the only in-tree client that was
using it instead of `Value::getString()`.
Part of PR21532.
llvm-svn: 221951
|
| |
|
|
| |
llvm-svn: 221950
|
| |
|
|
|
|
| |
VS 2012 doesn't have fminf or fmaxf.
llvm-svn: 221949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This has most of what is needed for mips fast-isel call lowering for O32.
What is missing I will add on the next patch because this patch is already too large.
It should not be doing anything wrong but it will punt on some cases that it is basically
capable of doing.
The mechanism is there for parameters to be passed on the stack but I have not enabled it because it serves as a way for now to prevent some of the strange cases of O32 register passing that I have not fully checked yet and have some issues.
The Mips O32 abi rules are very complicated as far how data is passed in floating and integer registers.
However there is a way to think about this all very simply and this implementation reflects that.
Basically, the ABI rules are written as if everything is passed on the stack and aligned as such.
Once that is conceptually done, it is nearly trivial to reassign those locations to registers and
then all the complexity disappears.
So I have told tablegen that all the data is passed on the stack and during the lowering I fix
this by assigning to registers as per the ABI doc.
This has been my approach and you can line up what I did with the ABI document and see 1 to 1 what
is going on.
Test Plan: callabi.ll
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: jholewinski, echristo, ahatanak, llvm-commits, rfuhler
Differential Revision: http://reviews.llvm.org/D5714
llvm-svn: 221948
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for LLI failure on Windows\X86: http://llvm.org/PR5053
LLI.exe crashes on Windows\X86 when single precession floating point
intrinsics like the following are used: acos, asin, atan, atan2, ceil,
copysign, cos, cosh, exp, floor, fmin, fmax, fmod, log, pow, sin, sinh,
sqrt, tan, tanh
The above intrinsics are defined as inline-expansions in math.h, and are
not exported by msvcr120.dll (Win32 API GetProcAddress returns null).
For an FREM instruction, the JIT compiler generates a call to a stub for
the fmodf() intrinsic, and adds a relocation to fixup at load time. The
loader searches the libraries for the function, but fails because the
symbol is not exported. So, the call target remains NULL and the
execution crashes.
Since the math functions are loaded at JIT/runtime, the JIT can patch
CALL instruction directly instead of the searching the libraries'
exported symbols. However, this fix caused build failures due to
unresolved symbols like _fmodf at link time.
Therefore, the current fix defines helper functions in the Runtime
link/load library to perform the above operations. The address of these
helper functions are used to patch up the CALL instruction at load time.
Reviewers: lhames, rnk
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D5387
Patch by Swaroop Sridhar!
llvm-svn: 221947
|
| |
|
|
|
|
| |
Now you can pass references into constructors.
llvm-svn: 221946
|
| |
|
|
| |
llvm-svn: 221945
|
| |
|
|
|
|
|
| |
The escaping of the '\*' doesn't work with my combination of testing
tools.
llvm-svn: 221944
|
| |
|
|
| |
llvm-svn: 221943
|
| |
|
|
|
|
| |
constant expressions.
llvm-svn: 221942
|
| |
|
|
|
|
| |
select_cc is expanded on SI, so this was never matched.
llvm-svn: 221941
|
| |
|
|
|
|
|
|
|
|
| |
Windows defines NULL to 0, which when used as an argument to a variadic
function, is not a null pointer constant. As a result, Clang's
-Wsentinel fires on this code. Using '0' would be wrong on most 64-bit
platforms, but both MSVC and Clang make it work on Windows. Sidestep the
issue with nullptr.
llvm-svn: 221940
|
| |
|
|
|
|
|
|
|
| |
Load PRE."
This reverts commit r221924. It appears the commit was a bit premature and is causing
bot failures that need further investigation.
llvm-svn: 221939
|
| |
|
|
|
|
|
|
|
| |
in-lane shuffles that aren't always handled well by the current vector
shuffle lowering.
No functionality change yet, that will follow in a subsequent commit.
llvm-svn: 221938
|
| |
|
|
| |
llvm-svn: 221937
|
| |
|
|
| |
llvm-svn: 221936
|
| |
|
|
|
|
|
| |
These functions always return a single value and not all callers want to
push them into a SmallVector.
llvm-svn: 221934
|
| |
|
|
|
|
|
|
| |
of new warning for deprecated method call for receiver
of type 'id'. This addresses rdar://18960378 where
unintended warnings being issued.
llvm-svn: 221933
|
| |
|
|
|
|
| |
Fixes the MSVC "14" build.
llvm-svn: 221932
|
| |
|
|
|
|
|
|
|
|
| |
Build failed here:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/14629/steps/build_Lld/logs/stdio
So I'm taking a shot in the dark that MSVC (whatever version that is)
can't cope with nested name specifiers with a decltype prefix.
llvm-svn: 221931
|
| |
|
|
| |
llvm-svn: 221930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As a follow-up to D6167, this patch fixes the test to account for
another difference between PowerPC and x86 systems.
On x86 if you branch to an invalid address, you get a SIGSEGV with PC
set to the invalid address (and si_addr in the siginfo struct also set
to the same address).
On PowerPC, you get a SIGSEGV with PC pointing at the branch
instruction, but si_addr set to the invalid address.
You can see this difference if you run the test case under gdb.
Reviewers: kcc, glider, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6226
llvm-svn: 221929
|
| |
|
|
|
|
|
|
|
| |
CodeGenDAGPatterns::PatternFragments
We might be able to use unique_ptr to handle ownership of the
TreePatternNodes too - looking into that next.
llvm-svn: 221928
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These checksums are ignored by llgs but some implementations require them to be specified properly.
Test Plan: Re-run llgs tests with the checksums and make sure we don't break anything.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6254
llvm-svn: 221927
|
| |
|
|
|
|
| |
requires TargetLoweringObjectFile to be passed.
llvm-svn: 221926
|
| |
|
|
|
|
| |
occasionally silently discards unknown -Wno-foo flags.
llvm-svn: 221925
|
| |
|
|
|
|
|
| |
Phabricator Revision: http://reviews.llvm.org/D6103
Patch by "Balaram Makam" <bmakam@codeaurora.org>!
llvm-svn: 221924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic FastISel code would bail, because it can't emit a sign-extend for
AArch64. This copies the code over and uses AArch64 specific emit functions.
This is not ideal and 'computeAddress' should handles this, so it can fold the
address computation into the memory operation.
I plan to clean up 'computeAddress' anyways, so I will add that in a future
commit.
Related to rdar://problem/18962471.
llvm-svn: 221923
|
| |
|
|
| |
llvm-svn: 221922
|
| |
|
|
|
|
|
|
|
|
|
| |
These were directly using the old base instruction
class, and specifying the wrong register classes
for operands. The operands can be the other special
inputs besides SGPRs. The op name was also being
directly used for the asm string, so this was printed
without any operands.
llvm-svn: 221921
|
| |
|
|
|
|
|
|
| |
If a function is just an unreachable, this would hit a
"this is not a MachO target" assertion because of setting
HasSubsectionViaSymbols.
llvm-svn: 221920
|
| |
|
|
| |
llvm-svn: 221919
|
| |
|
|
|
|
|
| |
is a re-commit of Doug's r154844 (modernized and updated to fit into current
Clang).
llvm-svn: 221918
|
| |
|
|
|
|
| |
Also give a proper error for other address spaces.
llvm-svn: 221917
|
| |
|
|
|
|
|
| |
It's not necessary. Also use complex patterns to allow
src modifier usage.
llvm-svn: 221916
|
| |
|
|
|
|
|
| |
Don't assert if we can return an error code, reuse existing
functionality like is64Bit().
llvm-svn: 221915
|
| |
|
|
| |
llvm-svn: 221914
|
| |
|
|
| |
llvm-svn: 221913
|
| |
|
|
| |
llvm-svn: 221912
|
| |
|
|
| |
llvm-svn: 221911
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
e.g. v_mad_f32 a, b, c -> v_mad_f32 b, a, c
This simplifies matching v_madmk_f32.
This looks somewhat surprising, but it appears to be
OK to do this. We can commute src0 and src1 in all
of these instructions, and that's all that appears
to matter.
llvm-svn: 221910
|
| |
|
|
|
|
| |
This removes the need for a special Read64.
llvm-svn: 221909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
same semantics as other SBDebugger::CreateTarget() functions.
The issues were:
- If you called this function with any arch other than the default target architecture, creating the target would fail because the Target::GetDefaultArchitecture() would not match the single architecture in the file specified. This caused running the test suite remotely with lldb-platform to fail many many tests due to the bad target.
- It would specify the currently selected platform which might not work for the specified platform
All other SBDebugger::CreateTarget calls do not assume an architecture or platform and if they aren't specified, they don't auto select the wrong one for you.
With this fix, SBTarget SBDebugger::CreateTarget (const char *filename) now behaves like the other SBDebugger::CreateTarget() variants.
llvm-svn: 221908
|
| |
|
|
|
|
| |
to update the SDK directory infos if needed before we start using m_sdk_directory_infos.
llvm-svn: 221907
|
| |
|
|
|
|
| |
reinterpret_cast from NativeProcessProtocol* to NativeProcessLinux*.
llvm-svn: 221906
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Normally entries can only move to a lower address, but when that wasn't viable,
the user's block was considered anyway. Unfortunately, it went via
createNewWater which wasn't designed to handle the case where there's already
an island after the block.
Unfortunately, the test we have is slow and fragile, and I couldn't reduce it
to anything sane even with the @llvm.arm.space intrinsic. The test change here
is recreating the previous one after the change.
rdar://problem/18545506
llvm-svn: 221905
|
| |
|
|
|
|
|
|
|
| |
We were using a naive heuristic to determine whether a basic block already had
an unconditional branch at the end. This mostly corresponded to reality
(assuming branches got optimised) because there's not much point in a branch to
the next block, but could go wrong.
llvm-svn: 221904
|
| |
|
|
|
|
|
|
| |
Creating tests for the ConstantIslands pass is very difficult, since it depends
on precise layout details. Having the ability to precisely inject a number of
bytes into the stream helps greatly.
llvm-svn: 221903
|
| |
|
|
| |
llvm-svn: 221901
|