| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 224835
|
|
|
|
|
|
|
|
|
| |
The current code leaves the first event in the trace part uninitialized
(from the previous thread). It can cause unpredictable behavior
during stack/mutexset restoration.
Initialize the first event to a fake harmless memory access.
llvm-svn: 224834
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 224833
|
|
|
|
| |
llvm-svn: 224832
|
|
|
|
|
|
|
|
|
| |
If a regular symbol has microMIPS-bit we need to stop linking. Now the
LLD does not check the `applyRelocation` return value and continues
linking anyway. As a temporary workaround use the `llvm_unreachable`
call to stop the linker.
llvm-svn: 224831
|
|
|
|
|
|
|
| |
The LLD output in the YAML mode depends on LLD_RUN_ROUNDTRIP_TEST
environment variable. Do not check unimportant YAML items like section-name.
llvm-svn: 224830
|
|
|
|
|
|
|
| |
No functional changes.
The documentation is coming.
llvm-svn: 224829
|
|
|
|
|
|
|
| |
It's possible to have a prior definition of a symbol in module asm.
Raise an error instead of crashing.
llvm-svn: 224828
|
|
|
|
| |
llvm-svn: 224827
|
|
|
|
|
|
|
| |
The change is rather large but mainly it just adds handling of new relocations,
PLT entries etc.
llvm-svn: 224826
|
|
|
|
|
|
|
|
|
| |
Bob Wilson pointed out the unnecessary checks that had been committed to the
instruction check predicates. The check was meant to ensure that the check was
not accidentally applied to non-ARM instructions. This is better served as an
assertion rather than a condition check.
llvm-svn: 224825
|
|
|
|
|
|
|
|
| |
This is mostly useful for testing, as the only other way of specifying
activation options (Android system property) is system-wide and affects
concurrently running tests.
llvm-svn: 224824
|
|
|
|
| |
llvm-svn: 224823
|
|
|
|
| |
llvm-svn: 224822
|
|
|
|
|
|
| |
File mapping offset was calculated by offsetting (uptr *) instead of (char *).
llvm-svn: 224821
|
|
|
|
| |
llvm-svn: 224820
|
|
|
|
|
|
| |
Ouch.
llvm-svn: 224819
|
|
|
|
|
|
| |
It used to pass by chance and started failing on recent Android builds.
llvm-svn: 224818
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 224817
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 224816
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 224815
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 224814
|
|
|
|
| |
llvm-svn: 224813
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This test failed because clang compiled the call to memset() into a
single sth instruction, instead of a call. Fix it by using write() instead
of memset().
Reviewers: kcc, samsonov, garious, eugenis
Reviewed By: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6776
llvm-svn: 224812
|
|
|
|
|
|
|
|
|
| |
.set directives may be overridden by other .set directives as well as
label definitions.
This fixes PR22019.
llvm-svn: 224811
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correct the line information generation for preprocessed assembly. Although we
tracked the source information for the macro instantiation, we failed to account
for the fact that we were instantiating a macro, which is populated into a new
buffer and that the line information would be relative to the definition rather
than the actual instantiation location. This could cause the line number
associated with the statement to be very high due to wrapping of the difference
calculated for the preprocessor line information emitted into the stream.
Properly calculate the line for the macro instantiation, referencing the line
where the macro is actually used as GCC/gas do.
The test case uses x86, though the same problem exists on any other target using
the LLVM IAS.
llvm-svn: 224810
|
|
|
|
|
|
|
|
| |
AdSize16/32/64 flags.
This removes a hardcoded list of instructions in the CodeEmitter. Eventually I intend to remove the predicates on the affected instructions since in any given mode two of them are valid if we supported addr32/addr16 prefixes in the assembler.
llvm-svn: 224809
|
|
|
|
| |
llvm-svn: 224808
|
|
|
|
| |
llvm-svn: 224807
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This function constructs the main liverange by merging all subranges if
subregister liveness tracking is available. This should be slightly
faster to compute instead of performing the liveness calculation again
for the main range. More importantly it avoids cases where the main
liverange would cover positions where no subrange was live. These cases
happened for partial definitions where the actual defined part was dead
and only the undefined parts used later.
The register coalescing requires that every part covered by the main
live range has at least one subrange live.
I also expect this function to become usefull later for places where the
subranges are modified in a way that it is hard to correctly fix the
main liverange in the machine scheduler, we can simply reconstruct it
from subranges then.
llvm-svn: 224806
|
|
|
|
|
|
| |
unused lanes.
llvm-svn: 224805
|
|
|
|
|
|
|
| |
Completely empty subranges are not allowed and must be removed when
subreg liveness is enabled.
llvm-svn: 224804
|
|
|
|
|
|
|
|
| |
Without a reference the code did not remember when moving the iterators
of the subranges/registerunit ranges forward and instead would scan from
the beginning again at the next position.
llvm-svn: 224803
|
|
|
|
|
|
| |
This finishes the fix partially applied by r224782.
llvm-svn: 224802
|
|
|
|
|
|
|
|
|
| |
Patch by Ramkumar Ramachandra <artagnon@gmail.com>.
Also remove Llvm_executionengine.get_pointer_to_global, as it
is actually deprecated and didn't appear in a stable release.
llvm-svn: 224801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
within a partition of an alloca in SROA.
This reflects the fact that the organization of the slices isn't really
ideal for analysis, but is the naive way in which the slices are
available while we're processing them in the core partitioning
algorithm.
It is possible we could improve matters, and I've left a FIXME with
one of my ideas for how to do this, but it is a lot of work, the benefit
is somewhat minor, and it isn't clear that it would be strictly better.
=/ Not really satisfying, but I'm out of really good ideas.
This also improves one place where the debug logging failed to mark some
split partitions. Now we log in one place, slightly later, and with
accurate information about whether the slice is split by the partition
being rewritten.
llvm-svn: 224800
|
|
|
|
|
|
|
| |
of a DW_TAG_ptr_to_member_type.
This restores the behavior from before r224780-r224781.
llvm-svn: 224799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
operate in terms of the new Partition class, and generally have a more
clear set of arguments. No functionality changed.
The most notable improvements here are consistently using the
terminology of 'partition' for a collection of slices that will be
rewritten together and 'slice' for a region of an alloca that is used by
a particular instruction.
This also makes it more clear that the split things are actually slices
as well, just ones that will be split by the proposed partition.
This doesn't yet address the confusing aspects of the partition's
interface where slices that will be split by the partition and start
prior to the partition are accesssed via Partition::splitSlices() while
the core range of slices exposed by a Partition includes both unsplit
slices and slices which will be split by the end, but started within the
offset range of the partition. This is particularly hard to address
because the algorithm which computes partitions quite literally doesn't
know which slices these will end up being until too late. I'm looking at
whether I can fix that or not, but I'm not optimistic. I'll update the
comments and/or names to further explain this either way. I've also
added one FIXME in this patch relating to this confusion so that I don't
forget about it.
llvm-svn: 224798
|
|
|
|
| |
llvm-svn: 224797
|
|
|
|
| |
llvm-svn: 224796
|
|
|
|
| |
llvm-svn: 224795
|
|
|
|
|
|
| |
place to fix I think.
llvm-svn: 224794
|
|
|
|
| |
llvm-svn: 224793
|
|
|
|
| |
llvm-svn: 224792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* /Zc:trigraphs and /Zc:trigraphs- are now honored
* /Zc:strictStrings is now honored
* /Zc:auto is now honored/ignored (clang does the Right Thing for this already)
Also add a dedicated test for the various /Zc: flags.
clang-cl doesn't always agree with cl.exe on the default values for /Zc flags.
For example, I think clang always behaves as if /Zc:inline is passed, and
warns if the user explicitly passes /Zc:inline-
Fixes PR21974.
llvm-svn: 224791
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-trigraphs is now an alias for -ftrigraphs. -fno-trigraphs makes it possible
to explicitly disable trigraphs, which couldn't be done before.
clang -std=c++11 -fno-trigraphs
now builds without GNU extensions, but with trigraphs disabled. Previously,
trigraphs were only disabled in GNU modes or with -std=c++1z.
Make the new -f flags the cc1 interface too. This requires changing -trigraphs
to -ftrigraphs in a few cc1 tests.
Related to PR21974.
llvm-svn: 224790
|
|
|
|
|
|
| |
coverage for the entire process as a single bit set, and if coverage_bitset=1 actually emit that bitset
llvm-svn: 224789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On non-Darwin PPC64, the TOC reload needs to come directly after the bctrl
instruction (for indirect calls) because the 'bctrl/ld 2, 40(1)' instruction
sequence is interpreted by the unwinding code in libgcc. To make sure these
occur as a pair, as with other pairings interpreted by the linker, fuse the two
instructions into one instruction (for code generation only).
In the future, we might wish to do this by emitting CFI directives instead,
but this solution is simpler, and mirrors what GCC does. Additional discussion
on this point is contained in the PR.
Fixes PR22015.
llvm-svn: 224788
|
|
|
|
| |
llvm-svn: 224787
|
|
|
|
| |
llvm-svn: 224786
|