| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Clang should emit "atomicrmw umin/umax" instead of "atomicrmw min/max".
Reviewers: eliben, tra
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12487
llvm-svn: 246455
|
| |
|
|
|
|
|
|
|
|
| |
For targets like Android that depends on libgcc's emulated thread local storage.
clang/llvm can generate calls to __emutls_get_address since
http://reviews.llvm.org/D10522 and http://reviews.llvm.org/D10524
Differential Revision: http://reviews.llvm.org/D12001
llvm-svn: 246454
|
| |
|
|
|
|
| |
This fixes a regression introduced in r246151.
llvm-svn: 246453
|
| |
|
|
|
|
| |
Removes some boilerplate code. No functionality change intended.
llvm-svn: 246452
|
| |
|
|
| |
llvm-svn: 246451
|
| |
|
|
|
|
|
|
| |
attribute"
This reverts commit 5e3bfbb38eb3fb6f568b107f6b239e0aa4c5f334.
llvm-svn: 246450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to repress sanitization. Move attribute for repressing sanitization to
operator delete for User, MDNode.
Summary: In response to bug 24578, reported against failing LLVM test.
Reviewers: chandlerc, rsmith, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12335
llvm-svn: 246449
|
| |
|
|
|
|
|
| |
The CMAKE_CURRENT_BINARY_DIR is only necessary on the DEPENDS part of
the add_custom_command to build the Fortran Modules.
llvm-svn: 246448
|
| |
|
|
| |
llvm-svn: 246447
|
| |
|
|
|
|
| |
other macros
llvm-svn: 246446
|
| |
|
|
| |
llvm-svn: 246445
|
| |
|
|
| |
llvm-svn: 246444
|
| |
|
|
|
|
|
|
| |
Instead of building domains with MaxLoopDepth dimensions, we now build
the domains such that they have the right amount of dimensions all the
time.
llvm-svn: 246443
|
| |
|
|
| |
llvm-svn: 246442
|
| |
|
|
|
|
|
|
|
|
| |
Before this commit we did this only for Arguments or Constants, but indeed
an instruction may define a value a lot higher up in the dominance tree, but
the actual write generally needs to happen right before branching to the
PHI node. Otherwise, the writes of different branches into PHI nodes may get
intermixed if they lay higher up in the dominance tree.
llvm-svn: 246441
|
| |
|
|
| |
llvm-svn: 246440
|
| |
|
|
|
|
|
|
| |
Added tests for encoding.
Differential Revision: http://reviews.llvm.org/D11979
llvm-svn: 246439
|
| |
|
|
|
|
|
|
|
|
| |
Proper diagnostic and resolution of mangled names conflicts between C++ methods
and C functions. This patch implements support for functions/methods only;
support for variables is coming separately.
Differential Revision: http://reviews.llvm.org/D11297
llvm-svn: 246438
|
| |
|
|
|
|
|
|
|
| |
"modernize/"
These checks are focusing on migrating the code from C++98/03 to C++11, so they
belong to the modernize module.
llvm-svn: 246437
|
| |
|
|
|
|
|
|
| |
Added tests for intrinsics and encoding.
Differential Revision: http://reviews.llvm.org/D12491
llvm-svn: 246436
|
| |
|
|
|
|
|
|
| |
According to `man freopen`, passing NULL instead of a filename is valid, however the current implementation of the interceptor assumes this parameter is non-NULL. Let's fix that and add a test case.
Differential Revision: http://reviews.llvm.org/D11389
llvm-svn: 246435
|
| |
|
|
| |
llvm-svn: 246434
|
| |
|
|
|
|
|
|
| |
There is no reason the loops in a region need to touch either entry or exit
block. Hence, we need to look through all loops that may touch the region as
well as their children to understand if our region has at least two loops.
llvm-svn: 246433
|
| |
|
|
|
|
|
|
| |
Added tests for encoding.
Differential Revision: http://reviews.llvm.org/D11973
llvm-svn: 246432
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D11941
llvm-svn: 246431
|
| |
|
|
|
|
|
|
| |
according to the Intel Spec
Differential Revision: http://reviews.llvm.org/D12274
llvm-svn: 246430
|
| |
|
|
|
|
|
|
|
| |
While ignoring read-only scalar dependences it was not necessary to consider
store instructins, but as store instructions can be the target of a scalar
read-only dependency we need to consider them for the construction of scalar
read-only dependences.
llvm-svn: 246429
|
| |
|
|
|
|
|
|
| |
Added tests for intrinsics and encoding.
Differential Revision: http://reviews.llvm.org/D12270
llvm-svn: 246428
|
| |
|
|
|
|
|
|
|
| |
Our OpenMP code generation generated part of its launching code directly into
the start basic block and without this change the scalar initialization was
run _after_ the OpenMP threads have been launched. This resulted in
uninitialized scalar values to be used.
llvm-svn: 246427
|
| |
|
|
| |
llvm-svn: 246426
|
| |
|
|
|
|
|
| |
Before we only checked if certain instructions can be expanded by us. Now we
check any value, including function arguments.
llvm-svn: 246425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rules for dllexported symbols are overly complicated due to
x86 name decoration, fuzzy symbol resolution, and the fact that
one symbol can be resolved by so many different names. The rules
are probably intended to be "intuitive", so that users don't have
to understand the name mangling schemes, but it seems that it can
lead to unintended symbol exports.
To make it clear what I'm trying to do with this patch, let me
write how the export rules are subtle and complicated.
- x86 name decoration: If machine type is i386 and export name
is given by a command line option, like /export:foo, the
real symbol name the linker has to search for is _foo because
all symbols are decorated with "_" prefixes. This doesn't happen
on non-x86 machines. This automatic name decoration happens only
when the name is not C++ mangled.
However, the symbol name exported from DLLs are ones without "_"
on all platforms.
Moreover, if the option is given via .drectve section, no
symbol decoration is done (the reason being that the .drectve
section is created by a compiler and the compiler should always
know the exact name of the symbol, I guess).
- Fuzzy symbol resolution: In addition to x86 name decoration,
the linker has to look for cdecl or C++ mangled symbols
for a given /export. For example, it searches for not only
_foo but also _foo@<number> or ??foo@... for /export:foo.
Previous implementation didn't get it right. I'm trying to make
it as compatible with MSVC linker as possible with this patch
however the rules are. The new code looks a bit messy to me, but
I don't think it can be simpler due to the ad-hoc-ness of the rules.
llvm-svn: 246424
|
| |
|
|
|
|
|
|
|
| |
AggressiveAntiDepBreaker was doing some EarlyClobber checking, but was not
checking that the register being potentially renamed was defined by an
early-clobber def where there was also a use, in that instruction, of the
register being considered as the target of the rename. Fixes PR24014.
llvm-svn: 246423
|
| |
|
|
|
|
| |
Added codegen for array section in 'depend' clause of 'task' directive. It emits to pointers, one for the begin of array section and another for the end of array section. Size of the section is calculated as (end + 1 - start) * sizeof(basic_element_type).
llvm-svn: 246422
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If run with other locales (like French),
the decode operation might fail
Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D12432
llvm-svn: 246421
|
| |
|
|
|
|
|
|
|
|
| |
Even though these are not strictly necessary for sequential code generation,
we still model both for sequential and parallel code generation to reduce
the set of configurations that needs to be tested. If this turns out, against
what we currently see, to be significant overhead, we can decide to limit this
feature again to parallel code-generation use cases only.
llvm-svn: 246420
|
| |
|
|
| |
llvm-svn: 246419
|
| |
|
|
| |
llvm-svn: 246418
|
| |
|
|
| |
llvm-svn: 246417
|
| |
|
|
|
|
|
|
| |
It is currently failing with "'__uncaught_exception': identifier not found"
error. I guess it is due to r246219 because after that change, eh.h is
included only when threading is enabled.
llvm-svn: 246416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
JumpThreading shouldn't duplicate a convergent call, because that would move a convergent call into a control-inequivalent location. For example,
if (cond) {
...
} else {
...
}
convergent_call();
if (cond) {
...
} else {
...
}
should not be optimized to
if (cond) {
...
convergent_call();
...
} else {
...
convergent_call();
...
}
Test Plan: test/Transforms/JumpThreading/basic.ll
Patch by Xuetian Weng.
Reviewers: resistor, arsenm, jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12484
llvm-svn: 246415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scalar dependences between scop statements have caused troubles during parallel
code generation as we did not pass on the new stack allocation created for such
scalars to the parallel subfunctions. This change now detects all scalar
reads/writes in parallel subfunctions, creates the allocas for these scalar
objects, passes the resulting memory locations to the subfunctions and ensures
that within the subfunction requests for these memory locations will return the
rewritten values.
Johannes suggested as a future optimization to privatizing some of the scalars
in the subfunction.
llvm-svn: 246414
|
| |
|
|
|
|
|
|
|
| |
This patch makes no assumptions on ABI past the ABI defined in
the OpenRISC 1000 spec except that the DWARF register numbers will
be 0-31 for registers r0-r31, which is true for both gcc and
clang at the moment.
llvm-svn: 246413
|
| |
|
|
|
|
| |
isn't found.
llvm-svn: 246412
|
| |
|
|
|
|
|
|
| |
This testcase required 2 copies of the same file, and the second
copy was missing. It was currently working because of a bug I'm
about to fix.
llvm-svn: 246411
|
| |
|
|
|
|
|
|
|
|
| |
The fix is trivial (The actual patch is 2 lines, but as it changes
indentation it looks like more).
clang does not produce this kind of (slightly bogus) debug info
anymore, thus I had to rely on a hand-crafted assembly test to trigger
that case.
llvm-svn: 246410
|
| |
|
|
|
|
|
| |
The current range cache will will just be hit more often, no
visible external change.
llvm-svn: 246409
|
| |
|
|
| |
llvm-svn: 246408
|
| |
|
|
|
|
| |
Now that resolved is templated anyway, we can use the regular Undefined.
llvm-svn: 246407
|
| |
|
|
|
|
|
|
|
| |
The value of an inlined subprogram low_pc attribute should not
get relocated, but it can happen that it matches the enclosing
function's start address and thus gets the generic treatment.
Special case it to avoid applying the PC offset twice.
llvm-svn: 246406
|