| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While working on uniform branching, I've hit a few cases where we emit
i1 SETCC operations.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D16233
llvm-svn: 258352
|
|
|
|
| |
llvm-svn: 258350
|
|
|
|
| |
llvm-svn: 258348
|
|
|
|
| |
llvm-svn: 258347
|
|
|
|
| |
llvm-svn: 258346
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the necessary plumbing to cmake to build the sources related to
GlobalISel.
To build the sources related to GlobalISel, we need to add -DBUILD_GLOBAL_ISEL=ON.
By default, this is OFF, thus GlobalISel sources will not impact people that do
not explicitly opt-in.
Differential Revision: http://reviews.llvm.org/D15983
llvm-svn: 258344
|
|
|
|
| |
llvm-svn: 258343
|
|
|
|
|
|
| |
This removes support for mesa 11.0.x
llvm-svn: 258342
|
|
|
|
|
|
|
|
| |
dynamically.
Path by Jonathan Coe.
llvm-svn: 258341
|
|
|
|
| |
llvm-svn: 258340
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSan runtime is not itself instrumented, so we need to explicitly
clear shadow for function arguments before calling user-provided
functions from runtime (e.g. we already do this for several
interceptors).
I'm still crafting a test case that would demonstrate this issue
reliably, and will commit it later today.
llvm-svn: 258339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a new kind of operand bundle to LLVM denoted by the
`"gc-transition"` tag. Inputs to `"gc-transition"` operand bundle are
lowered into the "transition args" section of `gc.statepoint` by
`RewriteStatepointsForGC`.
This removes the last bit of functionality that was unsupported in the
deopt bundle based code path in `RewriteStatepointsForGC`.
Reviewers: pgavlin, JosephTremoulet, reames
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16342
llvm-svn: 258338
|
|
|
|
| |
llvm-svn: 258337
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some architecture specific ELF section flags might have the same value
(for example SHF_X86_64_LARGE and SHF_HEX_GPREL) and we have to check
machine architectures to select an appropriate set of possible flags.
The patch selects architecture specific flags into separate arrays
`ElfxxxSectionFlags` and combines `ElfSectionFlags` and `ElfxxxSectionFlags`
before pass to the `StreamWriter::printFlags()` method.
Differential Revision: http://reviews.llvm.org/D16269
llvm-svn: 258334
|
|
|
|
|
|
|
|
|
|
|
| |
The selection process being split into separate passes, we need generic opcodes
to translate the LLVM IR to target independent code.
This patch adds an opcode for addition: G_ADD.
Differential Revision: http://reviews.llvm.org/D15472
llvm-svn: 258333
|
|
|
|
| |
llvm-svn: 258332
|
|
|
|
|
|
|
| |
STT_FILE symbols usually contain source file names. It is redundant
to keep this information in the output file.
llvm-svn: 258331
|
|
|
|
| |
llvm-svn: 258330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a symbol S shows up in an expression in assembly there are two
possible interpretations
* The expression is referring to the value of S in this file.
* The expression is referring to the value after symbol resolution.
In the first case the assembler can reason about the value and try to
produce a relocation.
In the second case, that is only possible if the symbol cannot be
preempted.
Assemblers are not very consistent about which interpretation gets used.
This changes MC to agree with GAS in the case of an expression of the
form "Sym - WeakSym".
llvm-svn: 258329
|
|
|
|
|
|
| |
Patch by Kwasi Mensah, thank you.
llvm-svn: 258328
|
|
|
|
|
|
|
| |
the same temporary file, otherwise there is a race condition when using
parallel make jobs.
llvm-svn: 258327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test case will crash without this patch because the subsequent call to
hasUnsafeAlgebra() assumes that the call instruction is an FPMathOperator
(ie, returns an FP type).
This part of the function signature check was omitted for the sqrt() case,
but seems to be in place for all other transforms.
Before:
http://reviews.llvm.org/rL257400
...we would have needlessly continued execution in optimizeSqrt(), but the
bug was harmless because we'd eventually fail some other check and return
without damage.
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=26211
Differential Revision: http://reviews.llvm.org/D16198
llvm-svn: 258325
|
|
|
|
| |
llvm-svn: 258324
|
|
|
|
| |
llvm-svn: 258323
|
|
|
|
|
|
| |
Patch by Aleksei Sidorin.
llvm-svn: 258322
|
|
|
|
|
|
| |
Patch by Adrian Zgorzałek.
llvm-svn: 258321
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was support for writing the AArch64 big endian data fixup entries in
the .eh_frame section in BE. This is changed to write all such fixup
entries in BE with no restriction on the section. This is similar to
the existing support for fixup entries for ARM.
A test is added to check the length field in the .debug_line section as
this is an example of where such a fixup occurs.
Differential Revision: http://reviews.llvm.org/D16064
llvm-svn: 258320
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D16304
llvm-svn: 258319
|
|
|
|
| |
llvm-svn: 258318
|
|
|
|
| |
llvm-svn: 258317
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16296
llvm-svn: 258316
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch marks some known failures and puts on expectedFailureLinux decorator to have testsuite xfail them.
Affected tests are:
test/functionalities/watchpoint/step_over_watchpoint.py
test/functionalities/watchpoint/watchpoint_set_command/TestWatchLocationWithWatchSet.py
test/tools/lldb-server/TestGdbRemoteSingleStep.py
test/tools/lldb-server/TestGdbRemote_vCont.py
llvm-svn: 258315
|
|
|
|
|
|
| |
This reverts commit r258255 and r258274, as it was breaking the AArch64 bot.
llvm-svn: 258314
|
|
|
|
|
|
|
| |
cxa_demangle's default size for a long double is 10 bytes. Hexagon
only has an 8 byte long double though.
llvm-svn: 258313
|
|
|
|
|
|
|
|
|
|
| |
string related instructions
There was a bug in my rL258132 because there's an overloading of the "movsd" and "cmpsd" instructions, e.g. movsd can be either "Move Data from String to String" (the case I wanted to handle) or "Move or Merge Scalar Double-Precision Floating-Point Value" (the case that causes the asserts).
Added code for escaping the unfamiliar scenarios and falling back to old behviour.
Also changed the asserts to llvm_unreachable.
llvm-svn: 258312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libcxxabi uses the C99 library's %a format specifier to turn a floating
point value into a hexadecimal string representation. The %a format
specifier is rather loosely defined in the C spec though, and some C
libraries emit a different (but valid) string for a given floating
point value. In particular, the C spec only requires that there is a
single, non-zero hexadecimal digit on the left of the decimal point.
Given that constraint, there are typically four different valid
representations of a floating point number. I have updated the test to
accept any of the valid representations for demangled floating
point literals.
llvm-svn: 258311
|
|
|
|
|
|
|
|
|
|
|
| |
If converter was somewhat careless about "diamond" cases, where there
was no join block, or in other words, where the true/false blocks did
not have analyzable branches. In such cases, it was possible for it to
remove (needed) branches, resulting in a loss of entire basic blocks.
Differential Revision: http://reviews.llvm.org/D16156
llvm-svn: 258310
|
|
|
|
|
|
|
|
| |
implementation.
Differential Revision: http://reviews.llvm.org/D16350
llvm-svn: 258309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AArch64 .inst directive was implemented using EmitIntValue, which resulted
in both $x and $d (code and data) mapping symbols being emitted at the same
address. This fixes it to only emit the $x mapping symbol.
EmitIntValue also emits the value in big-endian order when targeting big-endian
systems, but instructions are always emitted in little-endian order for
AArch64.
Differential Revision: http://reviews.llvm.org/D16349
llvm-svn: 258308
|
|
|
|
|
|
| |
Allow to emit code for 'cancel' directive within 'sections' directive with single sub-section.
llvm-svn: 258307
|
|
|
|
|
|
|
|
| |
std::array should have "the same semantics as a struct holding a C-style array T[N] as its only
non-static data member", so the initialization should have one more level of braces. Hopefully,
no compiler will object to that.
llvm-svn: 258306
|
|
|
|
|
|
| |
Test has been passing at least the last 200 buildbot runs.
llvm-svn: 258305
|
|
|
|
|
|
| |
The test has been passing reliably the last 100 runs of the build bot.
llvm-svn: 258304
|
|
|
|
|
|
|
| |
Patch adds command 'language renderscript kernel coordinate' for printing the kernel index in (x,y,z) format.
This is done by walking the call stack and looking for a function with suffix '.expand', as well as the frame variables containing the coordinate data.
llvm-svn: 258303
|
|
|
|
| |
llvm-svn: 258300
|
|
|
|
|
|
|
|
| |
functions in 'private' clause.
OpenMP 4.5 allows to use non-static members of current class in non-static member functions in 'private' clause. Patch adds initial support for privatizing data members.
llvm-svn: 258299
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-existent
This addresses PR26060 where function lto_module_create() could return nullptr
but lto_get_error_message() returned an empty string.
The error() call after LTOModule::createFromFile() in llvm-lto is then removed
because any error from this function should go through the diagnostic handler in
llvm-lto which will exit the program. The error() call was added because this
previously did not happen when the file was non-existent. This is fixed by the
patch. (The situation that llvm-lto reports an error when the input file does
not exist is tested by llvm/tools/llvm-lto/error.ll).
Differential Revision: http://reviews.llvm.org/D16106
llvm-svn: 258298
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix a significant performance regression by introducing GlobalValueVisited field and reusing the map.
This is a follow up to r257823 that slowed down linking Chrome with LTO by 2.5x.
If you revert this commit, please, also revert r257823.
BUG=https://llvm.org/bugs/show_bug.cgi?id=26214
Reviewers: pcc, loladiro, joker.eph
Subscribers: krasin1, joker.eph, loladiro, pcc
Differential Revision: http://reviews.llvm.org/D16338
llvm-svn: 258297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SelectionDAG previously missed opportunities to fold constants into
GlobalAddresses in several areas. For example, given `(add (add GA, c1), y)`, it
would often reassociate to `(add (add GA, y), c1)`, missing the opportunity to
create `(add GA+c, y)`. This isn't often visible on targets such as X86 which
effectively reassociate adds in their complex address-mode folding logic,
however it is currently visible on WebAssembly since it currently has very
simple address mode folding code that doesn't reassociate anything.
This patch fixes this by making SelectionDAG fold offsets into GlobalAddresses
at the same times that it folds constants together, so that it doesn't miss any
opportunities to perform such folding.
Differential Revision: http://reviews.llvm.org/D16090
llvm-svn: 258296
|
|
|
|
| |
llvm-svn: 258295
|