| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
When selecting an extract instruction, we don't actually generate code but instead work out which register we are reading, and rewrite uses of the extract def to the source register. This is done via updateValueMap,.
However, its possible that the source register we are rewriting *to* to also have uses. If those uses are after a kill of the value we are rewriting *from* then we have uses after a kill and the verifier fails.
This code checks for the case where the to register is also used, and if so it clears all kill on the from register. This is conservative, but better that always clearing kills on the from register.
llvm-svn: 236897
|
|
|
|
|
|
|
|
|
| |
Refactored parts of the hardware loop pass to generate
more. Also, added more tests.
Differential Revision: http://reviews.llvm.org/D9568
llvm-svn: 236896
|
|
|
|
|
|
|
|
|
| |
XFAILing these does not work because the timeout is caught by the
top-level test infrastucture instead.
Might be llvm.org/pr22784
llvm-svn: 236895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are several unhandled edge cases in BasicAA's GetLinearExpression
method. This changes fixes outstanding issues, including zext / sext of
a constant with the sign bit set, and the refusal to decompose zexts or
sexts of wrapping arithmetic.
Test Plan: Unit tests added in //q.ext.ll//.
Patch by Nick White.
Reviewers: hfinkel, sanjoy
Reviewed By: hfinkel, sanjoy
Subscribers: sanjoy, llvm-commits, hfinkel
Differential Revision: http://reviews.llvm.org/D6682
llvm-svn: 236894
|
|
|
|
| |
llvm-svn: 236893
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thread-safe logging had been disabled because of a deadlock,
possibly due to a lock acquired during a signal handler.
This patch turns thread safe logging back on and also greatly
reduces the scope of the lock, confining it only to the code that
affects the underlying output stream, instead of all the code that
builds up the formatted log message. this should resolve the
issue surrounding the deadlock.
llvm-svn: 236892
|
|
|
|
| |
llvm-svn: 236891
|
|
|
|
|
|
|
|
|
|
|
| |
A trunc from i32 to i1 on x86_64 generates an instruction such as
%vreg19<def> = COPY %vreg9:sub_8bit<kill>; GR8:%vreg19 GR32:%vreg9
However, the copy here should only have the kill flag on the 32-bit path, not the 64-bit one.
Otherwise, we are killing the source of the truncate which could be used later in the program.
llvm-svn: 236890
|
|
|
|
| |
llvm-svn: 236889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
transitions from GC-aware code to code that is not GC-aware.
This changes the shape of the statepoint intrinsic from:
@llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 unused, ...call args, i32 # deopt args, ...deopt args, ...gc args)
to:
@llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 flags, ...call args, i32 # transition args, ...transition args, i32 # deopt args, ...deopt args, ...gc args)
This extension offers the backend the opportunity to insert (somewhat) arbitrary code to manage the transition from GC-aware code to code that is not GC-aware and back.
In order to support the injection of transition code, this extension wraps the STATEPOINT ISD node generated by the usual lowering lowering with two additional nodes: GC_TRANSITION_START and GC_TRANSITION_END. The transition arguments that were passed passed to the intrinsic (if any) are lowered and provided as operands to these nodes and may be used by the backend during code generation.
Eventually, the lowering of the GC_TRANSITION_{START,END} nodes should be informed by the GC strategy in use for the function containing the intrinsic call; for now, these nodes are instead replaced with no-ops.
Differential Revision: http://reviews.llvm.org/D9501
llvm-svn: 236888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I noticed this bug when deubging a WIP on LSR. I wonder whether and how we
should add a regression test for this.
Test Plan: no tests failed.
Reviewers: atrick
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D9536
llvm-svn: 236887
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test here was sinking the AND here to a lower BB:
%vreg7<def> = ANDWri %vreg8, 0; GPR32common:%vreg7,%vreg8
TBNZW %vreg8<kill>, 0, <BB#1>; GPR32common:%vreg8
which meant that vreg8 was read after it was killed.
This commit changes the code from clearing kill flags on the AND to clearing flags on all registers used by the AND.
llvm-svn: 236886
|
|
|
|
| |
llvm-svn: 236885
|
|
|
|
|
|
| |
OpenMP runtime library.
llvm-svn: 236884
|
|
|
|
|
|
|
| |
The test started working at some point, presumably fixed through the
delayed typo correction work.
llvm-svn: 236883
|
|
|
|
|
|
|
| |
This reverts commit r236867, as it was breaking multiple buildbots. Daniel
will look into it later.
llvm-svn: 236882
|
|
|
|
|
|
| |
Thanks to Daniel Jasper for pointing out the mistake.
llvm-svn: 236881
|
|
|
|
| |
llvm-svn: 236880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functions with available_externally linkage will not be emitted to object
files (they will just be undefined symbols), so it does not make sense to
put them in comdats.
Creates a second overload of maybeSetTrivialComdat that uses the GlobalObject
instead of the Decl, and uses that in several places that had the faulty
logic.
Differential Revision: http://reviews.llvm.org/D9580
llvm-svn: 236879
|
|
|
|
|
|
|
| |
This was omitted from http://reviews.llvm.org/D9441
(the irony is that that was to detect omissions in something else)
llvm-svn: 236878
|
|
|
|
| |
llvm-svn: 236877
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improved the AnalyzeBranch, InsertBranch, and RemoveBranch
functions in order to handle more of our branch instructions.
This requires changes to analyzeCompare and PredicateInstructions.
Specifically, we've added support for new value compare jumps,
improved handling of endloop, added more compare instructions,
and improved support for predicate instructions.
Differential Revision: http://reviews.llvm.org/D9559
llvm-svn: 236876
|
|
|
|
| |
llvm-svn: 236875
|
|
|
|
|
|
| |
This is done the same way as we're looking for libc++
llvm-svn: 236874
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides generation of .ARM.exidx & .ARM.extab sections which are
used for unwinding. The patch adds new content type typeARMExidx for atoms from
.ARM.exidx section and integration of atoms with such type to the ELF
ReaderWriter. exidx.test has been added with checking of contents of .ARM.exidx
section and .ARM.extab section.
Differential Revision: http://reviews.llvm.org/D9324
llvm-svn: 236873
|
|
|
|
|
|
|
|
| |
For PIE executables the type of the main executable is shared object
so we can't force that the main executable should have the type of
executable.
llvm-svn: 236870
|
|
|
|
|
|
|
| |
This reverts commit r236859, as it broke multiple builds. I'll investigate
and reapply when safe.
llvm-svn: 236869
|
|
|
|
|
|
| |
This is only for editor integrations.
llvm-svn: 236867
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9441
llvm-svn: 236865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
decoding a PSHUFB mask.
The function 'getTargetShuffleMask' already knows how to deal with PSHUFB nodes
where the mask node is a load from constant pool, and the constant pool node
is wrapped by a X86ISD::Wrapper node. This patch extends that logic by teaching
it how to also look through X86ISD::WrapperRIP.
This helps function combineX86ShufflesRecusively to combine more shuffle
sequences containing PSHUFB nodes if we are in RIPRel PIC mode.
Before this change, llc (with -relocation-model=pic -march=x86-64) was unable
to decode a pshufb where the mask was loaded from a constant pool. For example,
the no-op shuffle from test 'x86-fold-pshufb.ll' was not folded into its
operand, so instead of generating a single 'movaps' the backend always
generated a sub-optimal 'movdqa + pshufb' sequence.
Added test x86-fold-pshufb.ll.
llvm-svn: 236863
|
|
|
|
|
|
|
|
|
| |
GCC allows case-insensitive values for -mcpu, -march and -mtune options.
This patch implements the same behaviour for the -mcpu option.
Patch by Gabor Ballabas.
llvm-svn: 236859
|
|
|
|
|
|
|
|
| |
This patch implements ALUIPC and AUIPC instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8441
llvm-svn: 236858
|
|
|
|
|
|
|
|
|
|
| |
I'm not yet sure what's wrong with pexpect and I cannot reproduce this
problem locally. XFAIL these tests for now to reduce buildbot noise so
I can track down the remaining buildbot failures.
llvm.org/pr22784
llvm-svn: 236857
|
|
|
|
|
|
|
| |
Need to specify triple so that llvm emits the asm syntax that the
test expected.
llvm-svn: 236855
|
|
|
|
|
|
|
| |
Propagate the 'incomplete-format' state back through clang-format's command
line interace and adapt the emacs integration to show a better result.
llvm-svn: 236854
|
|
|
|
|
|
|
|
|
|
| |
It's reported to pass consistently on Linux now, and it passed for me
in local testing on FreeBSD. Remove the expectedFailureFreeBSD decorator
for now.
llvm.org/pr20274
llvm-svn: 236853
|
|
|
|
|
|
|
|
| |
This patch implements ADDIUPC and LWPC instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8415
llvm-svn: 236852
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular:
* If the difference between the longest and shortest element, we copped
out of column format completely. Now, we instead allow to arrange
these in a single column, essentially enforcing a one-per-line format.
* Allow column layout even if there are braced lists. Especially, if
there are many short lists, this can be beneficial. The bad case,
where there is a long nested init list is usually caught as we now
limit the length difference of the longest and shortest element.
llvm-svn: 236851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) check whether the alignment of the memory is sufficient for the
*merged* store or load to be efficient.
Not doing so can result in some ridiculously poor code generation, if
merging creates a vector operation which must be aligned but isn't.
2) DON'T check that the alignment of each load/store is equal. If
you're merging 2 4-byte stores, the first *might* have 8-byte
alignment, but the second certainly will have 4-byte alignment. We do
want to allow those to be merged.
llvm-svn: 236850
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7760
llvm-svn: 236849
|
|
|
|
|
|
|
| |
The macros for gcc atomic compare and swaps are defined for Power8 CPU's since
the functionality is provided in the back end.
llvm-svn: 236848
|
|
|
|
|
|
|
|
|
|
| |
Mark longjmp tests as XFAIL because longjmp assembly for mips is not yet implemented.
Reviewers: dsanders, dvyukov, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9526
llvm-svn: 236847
|
|
|
|
|
|
|
|
|
|
| |
llvm::Triple::getARMCPUForArch now returns nullptr for invalid -march
values, instead of silently translating it to arm7tdmi. Use this to
give an error message, which is consistent with how gcc behaves.
Differential Revision: http://reviews.llvm.org/D9602
llvm-svn: 236846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Restructure Triple::getARMCPUForArch so that invalid values will
return nullptr, while retaining the behaviour that an argument
specifying no particular architecture version will give a default
CPU. This will be used by clang to give an error on invalid -march
values.
Also restructure the extraction of the architecture version from
the MArch string a little to hopefully make what it's doing clearer.
Differential Revision: http://reviews.llvm.org/D9599
llvm-svn: 236845
|
|
|
|
|
|
|
|
|
|
|
| |
This test was failing on mips because mips addresses are 40-bit long.
Using regex for address solves this issue.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9516
llvm-svn: 236844
|
|
|
|
|
|
|
|
|
|
|
| |
If no temp directory specified by the user on android then fall back
to /data/local/tmp what is always present on the device. It removes
the dependency of specifying TMPDIR for executing platform commands
on android.
Differential revision: http://reviews.llvm.org/D9569
llvm-svn: 236843
|
|
|
|
| |
llvm-svn: 236842
|
|
|
|
| |
llvm-svn: 236841
|
|
|
|
|
|
| |
tests (MI)
llvm-svn: 236840
|
|
|
|
| |
llvm-svn: 236839
|