| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 233203
|
|
|
|
|
|
|
|
| |
within module cache.
http://reviews.llvm.org/D8597
llvm-svn: 233202
|
|
|
|
| |
llvm-svn: 233201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with empty file names.
Some languages, such as Go, have pre-defined structure types (e.g. "string"
is essentially a pointer/length pair) or pre-defined "typedef" types
(e.g. "error" is essentially a typedef for a specific interface type).
Such types do not have associated source location, so a Go frontend would
be correct not to associate a file name with such types.
This change relaxes the DIType verifier to permit unlocated types with
these tags.
Differential Revision: http://reviews.llvm.org/D8588
llvm-svn: 233200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows AVX blend instructions to handle insertion into the low
element of a 256-bit vector for the appropriate data types.
For f32, instead of:
vblendps $1, %xmm1, %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[1,2,3]
vblendps $15, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0,1,2,3],ymm0[4,5,6,7]
we get:
vblendps $1, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0],ymm0[1,2,3,4,5,6,7]
For f64, instead of:
vmovsd %xmm1, %xmm0, %xmm1 ## xmm1 = xmm1[0],xmm0[1]
vblendpd $3, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0,1],ymm0[2,3]
we get:
vblendpd $1, %ymm1, %ymm0, %ymm0 ## ymm0 = ymm1[0],ymm0[1,2,3]
For the hardware-neglected integer data types, I left a TODO comment in the
code and added regression tests for a follow-on patch.
Differential Revision: http://reviews.llvm.org/D8609
llvm-svn: 233199
|
|
|
|
|
|
|
|
| |
1. There were no CHECK-LABELs, so we could match instructions from the wrong function.
2. The use of zero operands meant multiple xor instructions could match some CHECKs.
3. The test was over-specified to need a Sandybridge CPU and Darwin triple.
llvm-svn: 233198
|
|
|
|
|
|
|
| |
This code is only compiled when LLVM_USE_INTEL_JITEVENTS, but at least we have
one buildbot where that's the case :)
llvm-svn: 233197
|
|
|
|
|
|
|
| |
To complement getSplat. This is more general than the binary
decomposition method as it also handles non-pow2 splat sizes.
llvm-svn: 233195
|
|
|
|
|
|
| |
* Use target triple instead of host platform
llvm-svn: 233194
|
|
|
|
|
|
|
|
|
|
| |
Effeted pathes:
* Host/posix/*
* Platform/gdb-server/*
* Process/Linux/*
* Process/POSIX/*
llvm-svn: 233193
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 233192
|
|
|
|
|
|
|
| |
Hopefully makes it a bit easier to understand what's going on.
No functional change intended.
llvm-svn: 233191
|
|
|
|
|
|
| |
Treat a test run as remote run also if lldb.remote_platform is set.
llvm-svn: 233190
|
|
|
|
|
|
|
|
| |
Some recent changes to sancov.py broke ASAN for big endian. This fixes it.
http://reviews.llvm.org/D8594
llvm-svn: 233189
|
|
|
|
|
|
|
| |
The other version doesn't properly work with our internal test runner,
which sets pipefail.
llvm-svn: 233188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous logic was to first try without relocations at all
and failing that stop on the first defined symbol.
That was inefficient and incorrect in the case part of the
expression could be simplified and another part could not
(see included test).
We now stop the evaluation when we get to a variable whose value
can change (i.e. is weak).
llvm-svn: 233187
|
|
|
|
|
|
|
|
|
| |
the separate function
That keeps "extracting" logic into the single place and removes a VC++
compilation warning.
llvm-svn: 233186
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds the --server argument to lldb-server platform which when specified will allow multiple simultaneous connections by forking off to handle each individual connection. This will allow us to run the remote tests in parallel.
Test Plan:
Run: lldb-server platform --listen *:1234 --server
Connect from multiple lldb clients simultaneously.
I will also test running the test suite remotely with multiple simultaneous jobs.
Differential Revision: http://reviews.llvm.org/D8452
llvm-svn: 233185
|
|
|
|
| |
llvm-svn: 233184
|
|
|
|
|
|
|
| |
Added test Float2Int/float2int-optnone.ll to verify that pass Float2Int
is not run on optnone functions.
llvm-svn: 233183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that we're building and testing the CompileOnDemand layer, at least
in a basic way.
Currently x86-64 only, and with limited to no library calls enabled (depending
on host platform). Patches welcome. ;)
To enable access to the lazy JIT, this patch replaces the '-use-orcmcjit' lli
option with a new option:
'-jit-kind={ mcjit | orc-mcjit | orc-lazy }'.
All regression tests are updated to use the new option, and one trivial test of
the new lazy JIT is added.
llvm-svn: 233182
|
|
|
|
|
|
| |
Also, removed unused check lines from test atomic6432.ll.
llvm-svn: 233181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on OSX 10.9
On OS X 10.9 /usr/bin/atos prints the following warning upon invocation:
--
Warning: /usr/bin/atos is moving and will be removed from a future OS X release.
It is now available in the Xcode developer tools to be invoked via: `xcrun atos`
To silence this warning, pass the '-d' command-line flag to this tool.
--
AtosSymbolizer treats the warning as the symbolization result for the first PC passed to the symbolizer. As a result, for each of the following PCs the file:line info for the previous PC is printed, e.g.:
==97926==ERROR: AddressSanitizer: attempting double-free on 0x60200000dfb0 in thread T0:
==97926==Using atos at user-specified path: /usr/bin/atos
==97926==Using dladdr symbolizer.
#0 0x1007407e0 in -- (+0x427e0)
#1 0x1006f6f25 in wrap_free asan_malloc_mac.cc:114
#2 0x7fff916e05fc in main atos-symbolizer.cc:17
#3 0x0 (<unknown module>)
Unfortunately atos doesn't accept the -d switch on OSX versions other than 10.9, thus we have to check for the OSX version.
llvm-svn: 233180
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation only read out the first element of the
underlying storage array. Because of it only the first 32 (on x86) or
the first 64 (on x86_64) element was displayed.
Differential revision: http://reviews.llvm.org/D8585
llvm-svn: 233179
|
|
|
|
|
|
|
|
|
|
|
| |
Gcc for android use the leal instruction to substract from the stack
pointer in the prologue of a function call. This patch add basic support
for evaluating this instruction to support stack unwinding on
android-x86.
Differential revision: http://reviews.llvm.org/D8583
llvm-svn: 233178
|
|
|
|
|
|
|
|
|
|
|
| |
On android x86_32 the long double is only 64 bits (compared to 80 bits
on linux x86_32) and on android x86_64 the long double is IEEEquad
(compared to x87DoubleExtended on linux x86_64). This CL creates new
TargetInfo classes for this targets to represent these differences.
Differential revision: http://reviews.llvm.org/D8357
llvm-svn: 233177
|
|
|
|
|
|
|
|
| |
The automatic conversion from long int to lldb::addr_t caused sign
extension but for a register read it is an unwanted behaviour. Fix with
forcing different conversion path.
llvm-svn: 233176
|
|
|
|
|
|
|
|
| |
where possible.
Now with a fix for PR23008 and extra regression test.
llvm-svn: 233175
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r233009 we gained specific check-llvm-* build targets for invoking
specific parts of the test suite, but they were copying the
dependencies for check-all, rather than just listing the dependencies
for check-llvm.
This moves the creation of these targets next to the check-llvm
target, and uses that target's configuration rather than the check-all
config.
llvm-svn: 233174
|
|
|
|
|
|
| |
This turned the bots to red after r233172 which reverted r233156.
llvm-svn: 233173
|
|
|
|
|
|
|
|
| |
context lookup tables, we need to establish a stable ordering for constructing the hash table. This is trickier than it might seem."
This reverts commit r233156. It broke the bots.
llvm-svn: 233172
|
|
|
|
| |
llvm-svn: 233171
|
|
|
|
|
|
| |
functions from X86 MC layer. They haven't been used since CPU autodetection was removed from X86Subtarget.cpp.
llvm-svn: 233170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we try to find the end loc for a token, we have to re-lex the
token. This was running into a problem when we'd store the end loc of
a macro's coverage region, since we wouldn't actually be at the
beginning of a token when we tried to re-lex it, leading us to do
silly things (and eventually assert) when whitespace or comments
followed.
This pushes our use of getPreciseTokenLocEnd earlier, so that we won't
call it when it doesn't make sense to. It also removes an unnecessary
adjustment by 1 that was working around this problem in some cases.
llvm-svn: 233169
|
|
|
|
| |
llvm-svn: 233168
|
|
|
|
| |
llvm-svn: 233167
|
|
|
|
|
|
|
|
| |
target-independent callback management.
This is a prerequisite for adding orc-based lazy-jitting to lli.
llvm-svn: 233166
|
|
|
|
|
|
|
|
|
|
| |
At least one Linux bot [1] doesn't like my dwarfdump checks, so I've
disable those until I can investigate what's going on there. I'll
continue to track this in PR22792.
[1]: http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/22863
llvm-svn: 233165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of dropping subprograms that have been overridden, just set
their function pointers to `nullptr`. This is a minor adjustment to the
stop-gap fix for PR21910 committed in r224487, and fixes the crasher
from PR22792.
The problem that r224487 put a band-aid on: how do we find the canonical
subprogram for a `Function`? Since the backend currently relies on
`DebugInfoFinder` (which does a naive in-order traversal of compile
units and picks the first subprogram) for this, r224487 tried dropping
non-canonical subprograms.
Dropping subprograms fails because the backend *also* builds up a map
from subprogram to compile unit (`DwarfDebug::SPMap`) based on the
subprogram lists. A missing subprogram causes segfaults later when an
inlined reference (such as in this testcase) is created.
Instead, just drop the `Function` pointer to `nullptr`, which nicely
mirrors what happens when an already-inlined `Function` is optimized
out. We can't really be sure that it's the same definition anyway, as
the testcase demonstrates.
This still isn't completely satisfactory. Two flaws at least that I can
think of:
- I still haven't found a straightforward way to make this symmetric
in the IR. (Interestingly, the DWARF output is already symmetric,
and I've tested for that to be sure we don't regress.)
- Using `DebugInfoFinder` to find the canonical subprogram for a
function is kind of crazy. We should just attach metadata to the
function, like this:
define weak i32 @foo(i32, i32) !dbg !MDSubprogram(...) {
llvm-svn: 233164
|
|
|
|
|
|
| |
non-determinism here, I just got lucky a bunch of times on my system.
llvm-svn: 233163
|
|
|
|
|
|
|
|
|
| |
This fixes my stress tests non-determinism so far. However, I've not
started playing with templates, friends, or terrible macros. I've found
at least two more seeming instabilities and am just waiting for a test
case to actually trigger them.
llvm-svn: 233162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hints
Summary: Follow-up to the fix of PR22075.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7012
llvm-svn: 233161
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes PR22075.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6828
llvm-svn: 233160
|
|
|
|
|
|
| |
a subsequent commit in Clang.
llvm-svn: 233159
|
|
|
|
| |
llvm-svn: 233158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
green
Summary:
-Refer to bug https://buganizer.corp.google.com/issues/19893563
-Test log http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/1145
Test Plan: Run tests with different compiler and archs locally
Reviewers: sivachandra, ovyalov, chaoren, vharron
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8573
llvm-svn: 233157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lookup tables, we need to establish a stable ordering for constructing
the hash table. This is trickier than it might seem.
Most of these cases are easily handled by sorting the lookup results
associated with a specific name that has an identifier. However for
constructors and conversion functions, the story is more complicated.
Here we need to merge all of the constructors or conversion functions
together and this merge needs to be stable. We don't have any stable
ordering for either constructors or conversion functions as both would
require a stable ordering across types.
Instead, when we have constructors or conversion functions in the
results, we reconstruct a stable order by walking the decl context in
lexical order and merging them in the order their particular declaration
names are encountered. This doesn't generalize as there might be found
declaration names which don't actually occur within the lexical context,
but for constructors and conversion functions it is safe. It does
require loading the entire decl context if necessary to establish the
ordering but there doesn't seem to be a meaningful way around that.
Many thanks to Richard for talking through all of the design choices
here. While I wrote the code, he guided all the actual decisions about
how to establish the order of things.
No test case yet because the test case I have doesn't pass yet -- there
are still more sources of non-determinism. However, this is complex
enough that I wanted it to go into its own commit in case it causes some
unforseen issue or needs to be reverted.
llvm-svn: 233156
|
|
|
|
| |
llvm-svn: 233155
|
|
|
|
|
|
|
| |
This test checks for the size of .idata section. Before r233128,
the size of the section is 0x45, but it's now 0x27.
llvm-svn: 233154
|
|
|
|
|
|
|
|
|
| |
Reverts the code change from r221168 and the relevant test.
It was a mistake to disable the combiner, and based on the ultimate
definition of 'optnone' we shouldn't have considered the test case
as failing in the first place.
llvm-svn: 233153
|