| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change merges adjacent 32 bit zero stores into a 64 bit zero store.
e.g.,
str wzr, [x0]
str wzr, [x0, #4]
becomes
str xzr, [x0]
Therefore, four adjacent 32 bit zero stores will be a single stp.
e.g.,
str wzr, [x0]
str wzr, [x0, #4]
str wzr, [x0, #8]
str wzr, [x0, #12]
becomes
stp xzr, xzr, [x0]
Reviewers: mcrosier, jmolloy, gberry, t.p.northover
Subscribers: aemerson, rengolin, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16933
llvm-svn: 260682
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Expand the simplify boolean expression check to handle implicit conversion of integral types to bool and improve the handling of implicit conversion of member pointers to bool.
Implicit conversion of member pointers are replaced with explicit comparisons to nullptr.
Implicit conversions of integral types are replaced with explicit comparisons to 0.
Patch by Richard Thomson.
llvm-svn: 260681
|
| |
|
|
|
|
|
|
|
|
|
| |
The DataLayout can calculate alignment of vectors based on the alignment
of the element type and the number of elements. In fact, it is the product
of these two values. The problem is that for vectors of N x i1, this will
return the alignment of N bytes, since the alignment of i1 is 8 bits. The
vector types of vNi1 should be aligned to N bits instead. Provide explicit
alignment for HVX vectors to avoid such complications.
llvm-svn: 260680
|
| |
|
|
|
|
|
| |
There is now a default name_suffix ('default') which should appease the buildbot
and reveal why this builder lacks a suffix.
llvm-svn: 260679
|
| |
|
|
|
|
|
|
|
|
|
| |
The DataLayout can calculate alignment of vectors based on the alignment
of the element type and the number of elements. In fact, it is the product
of these two values. The problem is that for vectors of N x i1, this will
return the alignment of N bytes, since the alignment of i1 is 8 bits. The
vector types of vNi1 should be aligned to N bits instead. Provide explicit
alignment for HVX vectors to avoid such complications.
llvm-svn: 260678
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds some TLS relocations and relaxations for AArch64.
Some Global-Dynamic relocation are handled by optimizing them to
Local-Exec (Initial-Exec is not yet supported). They are:
- R_AARCH64_TLSDESC_ADR_PAGE21
- R_AARCH64_TLSDESC_LD64_LO12_NC
- R_AARCH64_TLSDESC_ADD_LO12_NC
- R_AARCH64_TLSDESC_CALL
Also some Init-Exec is optimized to Local-Exec if possible. They are:
- R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21
- R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
Finally some Local-Exec relocation are handled in relocateOne:
- R_AARCH64_TLSLE_ADD_TPREL_HI12
- R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
This work is mainly for compiler bootstrap, where static binaries is
showing good progress (although shared object still lacking support
from both TLS aarch64 backend and some other issues).
llvm-svn: 260677
|
| |
|
|
|
|
| |
Found by msan.
llvm-svn: 260676
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a crash while parsing this code:
struct X {
friend constexpr int foo(X*) { return 12; }
static constexpr int j = foo(static_cast<X*>(nullptr));
};
Differential Revision: http://reviews.llvm.org/D16973
llvm-svn: 260675
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For pragma omp taskwait the runtime is called from the task context.
Therefore, the reentry frame information should be updated.
The information should be available for both taskwait event calls; therefore,
set before the first event and reset after the last event.
Patch by Joachim Protze
Differential Revision: http://reviews.llvm.org/D17145
llvm-svn: 260674
|
| |
|
|
|
|
|
|
| |
FLOOR.L.D instructions
Differential Revision: http://reviews.llvm.org/D17192
llvm-svn: 260673
|
| |
|
|
|
|
|
| |
There's no obvious reason it should fail in this way but it's the only change
on the blamelist. I suspect stale lit*.cfg's from previous builds.
llvm-svn: 260672
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The library functions defined in the C99 standard headers
are not available (OpenCL v1.2 s6.9.f).
This change stops treating OpenCL builtin functions as standard C lib
functions to eliminate warning messages about printf format string.
Patch by Liu Yaxun (Sam)!
Differential Revision: http://reviews.llvm.org/D16812
llvm-svn: 260671
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LLVMGetTargetMachineData has been removed, and LLVMGetDataLayout is
suggested to use. The LLVMGetDataLayout is exposed in go bindings.
So it's safe to remove the function.
Reviewers: bkramer
Subscribers: llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D17193
llvm-svn: 260670
|
| |
|
|
|
|
|
|
|
|
| |
The lit test-suite containing the unit tests needs to be explicitly specified
as an argument to lit.py since it is no longer discovered when the other tests
are run (because they are one directory deeper).
dfsan, lsan, and sanitizer_common don't show the same problem.
llvm-svn: 260669
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
node set rather than walking the SCC directly.
This directly exposes the functions and has already had null entries
filtered out. We also don't need need to handle optnone as it has
already been handled in the caller -- we never try to remove convergent
when there are optnone functions in the SCC.
With this change, the code for removing convergent should work with the
new pass manager and a different SCC analysis.
llvm-svn: 260668
|
| |
|
|
|
|
|
|
| |
I added portability warnings when int results are casted to long. I forgot to handle uint, ulong and ulonglong.
Tested on x86 and powerpc targets, hope it works now on all buildbots.
llvm-svn: 260667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with the test for a non-convergent intrinsic call.
While it is possible to use the call records to search for function
calls, we're going to do an instruction scan anyways to find the
intrinsics, we can handle both cases while scanning instructions. This
will also make the logic more amenable to the new pass manager which
doesn't use the same call graph structure.
My next patch will remove use of CallGraphNode entirely and allow this
code to work with both the old and new pass manager. Fortunately, it
should also get strictly simpler without changing functionality.
llvm-svn: 260666
|
| |
|
|
|
|
|
|
|
|
|
|
| |
portability problems.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17140
llvm-svn: 260665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contain logic to inspect the objects without running code.
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
|
| |
|
|
|
|
| |
on MSVC.
llvm-svn: 260663
|
| |
|
|
|
|
|
|
|
| |
With this option one can optionally override the architecture dependent
default library to use if no -stdlib= is provided on compiler invocation.
Differential Revision: http://reviews.llvm.org/D15920
llvm-svn: 260662
|
| |
|
|
|
|
|
| |
This will be needed for the next commit that allows to switch the default
C++ library which would otherwise make these tests fail.
llvm-svn: 260661
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was hardcoded to the static private size, but this
would be missing the offset and additional size for someday
when we have dynamic sizing.
Also stops always initializing flat_scratch even when unused.
In the future we should stop emitting this unless flat instructions
are used to access private memory. For example this will initialize
it almost always on VI because flat is used for global access.
llvm-svn: 260658
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 260657
|
| |
|
|
|
|
| |
Replace 'third' with 'fourth' in the description of the fourth argument.
llvm-svn: 260656
|
| |
|
|
| |
llvm-svn: 260655
|
| |
|
|
| |
llvm-svn: 260654
|
| |
|
|
|
|
| |
before I update it to be friendly with the new pass manager.
llvm-svn: 260653
|
| |
|
|
|
|
| |
class that makes it convenient to work with enumerators representing bit options.
llvm-svn: 260652
|
| |
|
|
|
|
|
|
|
| |
Introduce a subtarget feature for this, and leave the default with
the current behavior which assumes up to 16-byte loads/stores can
be used. The field also seems to have the ability to be set to 2 bytes,
but I'm not sure what that would be used for.
llvm-svn: 260651
|
| |
|
|
|
|
| |
every input N times)
llvm-svn: 260649
|
| |
|
|
|
|
| |
namespace for arguments.
llvm-svn: 260647
|
| |
|
|
|
|
|
| |
I don't think this was causing any real problems, so I'm not sure
how to test for this.
llvm-svn: 260646
|
| |
|
|
| |
llvm-svn: 260645
|
| |
|
|
| |
llvm-svn: 260644
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch by Jack Howarth.
When linking to libLLVM, don't also link to the component
libraries that constitute libLLVM.
Differential Revision: http://reviews.llvm.org/D16945
llvm-svn: 260641
|
| |
|
|
|
|
|
|
| |
in C99.
Patch by Jorge Teixeira!
llvm-svn: 260639
|
| |
|
|
| |
llvm-svn: 260637
|
| |
|
|
|
|
|
|
| |
Previously, if both A and B are ".ctors", both compCtors(A, B) and
compCtors(B, A) are true, which is a violation of the strict weak
ordering because such function is not antisymmetric.
llvm-svn: 260633
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSan adds a constructor to each translation unit that calls
__msan_init, and does nothing else. The idea is to run __msan_init
before any instrumented code. This results in multiple constructors
and multiple .init_array entries in the final binary, one per
translation unit. This is absolutely unnecessary; one would be
enough.
This change moves the constructors to a comdat group in order to drop
the extra ones.
llvm-svn: 260632
|
| |
|
|
| |
llvm-svn: 260631
|
| |
|
|
|
|
|
|
| |
Documentation change for: http://reviews.llvm.org/D17169
Differential Revision: http://reviews.llvm.org/D17175
llvm-svn: 260630
|
| |
|
|
|
|
|
|
|
|
| |
Updating sancov invocation on html_cov_dump.
sancov change: http://reviews.llvm.org/D17169
Differential Revision: http://reviews.llvm.org/D17171
llvm-svn: 260629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Multi-dso programs result in multiple coverage files dumped of the form
'<module_name>.<pid>.sancov'. When analyzing these coverage files it is
important to use correct corresponding object file.
This change removes the "-obj" sancov flag and lets user specify object
file names alongside coverage files. Sancov tool would match them using
<module_name> part of coverage file and short file name of the object
file.
Corresponding changes:
- compiler-rt: http://reviews.llvm.org/D17171
- docs: http://reviews.llvm.org/D17175
Differential Revision: http://reviews.llvm.org/D17169
llvm-svn: 260628
|
| |
|
|
|
|
|
|
|
|
| |
This patches teaches LVI to recognize clamp idioms (e.g. select(a > 5, a, 5) will always produce something greater than 5.
The tests end up being somewhat simplistic because trying to exercise the case I actually care about (a loop with a range check on a clamped secondary induction variable) ends up tripping across a couple of other imprecisions in the analysis. Ah, the joys of LVI...
Differential Revision: http://reviews.llvm.org/D16827
llvm-svn: 260627
|
| |
|
|
|
|
|
|
| |
SymbolFileDWARF doesn't have a DebugRanges. If this happens print a nice error message to prompt the user to file a bug and attach the offending DWARF file so we can get the correct compiler fixed.
<rdar://problem/24458016>
llvm-svn: 260626
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also, some cosmetic fixes.
Reviewers: arsenm, tstellarAMD
Subscribers: qcolombet, llvm-commits
Differential Revision: http://reviews.llvm.org/D17161
llvm-svn: 260625
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clearing the map ended up calling back into the TypeSystemMap to do lookups.
Not a good idea, and in this case it would cause a deadlock.
You would only see this when replacing the target contents after an exec, and only if you
had stopped before the exec, evaluated an expression, then continued
on to the point where you did the exec.
Fixed this by making sure the TypeSystemMap::Clear tears down the TypeSystems in the map before clearing the map.
I also add an expression before exec to the TestExec.py so that we'll catch this
issue if it crops up again in the future.
<rdar://problem/24554920>
llvm-svn: 260624
|
| |
|
|
| |
llvm-svn: 260623
|
| |
|
|
|
|
|
|
| |
functions, ask it whether it did provide them after the fact. Some versions of
glibc fail to compile if you make this request and don't also claim to be at
least GCC 4.3.
llvm-svn: 260622
|