| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 309654
|
|
|
|
|
|
| |
Pretty sure this will automatically promoted to match the type of the other operand of the subtract. There's plenty of other similar code around here without this cast.
llvm-svn: 309653
|
|
|
|
|
|
|
|
| |
This change makes -gdb-index 40% faster. My test case is self-linking lld.
Differential Revision: https://reviews.llvm.org/D36079
llvm-svn: 309652
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stack coloring pass need to maintain AliasAnalysis information when merging stack slots of different types.
Actually, there is a FIXME comment in StackColoring.cpp
// FIXME: In order to enable the use of TBAA when using AA in CodeGen,
// we'll also need to update the TBAA nodes in MMOs with values
// derived from the merged allocas.
But, TBAA has been already enabled in CodeGen without fixing this pass.
The incorrect TBAA metadata results in recent failures in bootstrap test on ppc64le (PR33928) by allowing unsafe instruction scheduling.
Although we observed the problem on ppc64le, this is a platform neutral issue.
This patch makes the stack coloring pass maintains AliasAnalysis information when merging multiple stack slots.
llvm-svn: 309651
|
|
|
|
| |
llvm-svn: 309650
|
|
|
|
| |
llvm-svn: 309649
|
|
|
|
| |
llvm-svn: 309648
|
|
|
|
|
|
| |
Inline8bitCounters
llvm-svn: 309647
|
|
|
|
| |
llvm-svn: 309646
|
|
|
|
| |
llvm-svn: 309645
|
|
|
|
| |
llvm-svn: 309644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As discussed on llvm-dev I've implemented the first basic steps towards
llvm-objcopy/llvm-objtool (name pending).
This change adds the ability to copy (without modification) 64-bit
little endian ELF executables that have SHT_PROGBITS, SHT_NOBITS,
SHT_NULL and SHT_STRTAB sections.
Patch by Jake Ehrlich
Differential Revision: https://reviews.llvm.org/D33964
llvm-svn: 309643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D31536 didn't really solve the problem it was
trying to solve; it got rid of the assertion failure, but we were still
scheduling the DAG incorrectly (mixing together instructions from
different calls), leading to a MachineVerifier failure.
In order to schedule the DAG correctly, we have to make sure we don't
schedule a node which should be blocked by an interference. Fix
ScheduleDAGRRList::PickNodeToScheduleBottomUp so it doesn't pick a node
like that.
The added call to FindAvailableNode() is the key change here; this makes
sure we don't try to schedule a call while we're in the middle of
scheduling a different call. I'm not sure this is the right approach; in
particular, I'm not sure how to prove we don't end up with an infinite
loop of repeatedly backtracking.
This also reverts the code change from D31536. It doesn't do anything
useful: we should never schedule an ADJCALLSTACKDOWN unless we've
already scheduled the corresponding ADJCALLSTACKUP.
Differential Revision: https://reviews.llvm.org/D33818
llvm-svn: 309642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adding part of the changes in D30369 (needed to make progress):
Current patch updates AliasAnalysis and MemoryLocation, but does _not_ clean up MemorySSA.
Original summary from D30369, by dberlin:
Currently, we have instructions which affect memory but have no memory
location. If you call, for example, MemoryLocation::get on a fence,
it asserts. This means things specifically have to avoid that. It
also means we end up with a copy of each API, one taking a memory
location, one not.
This starts to fix that.
We add MemoryLocation::getOrNone as a new call, and reimplement the
old asserting version in terms of it.
We make MemoryLocation optional in the (Instruction, MemoryLocation)
version of getModRefInfo, and kill the old one argument version in
favor of passing None (it had one caller). Now both can handle fences
because you can just use MemoryLocation::getOrNone on an instruction
and it will return a correct answer.
We use all this to clean up part of MemorySSA that had to handle this difference.
Note that literally every actual getModRefInfo interface we have could be made private and replaced with:
getModRefInfo(Instruction, Optional<MemoryLocation>)
and
getModRefInfo(Instruction, Optional<MemoryLocation>, Instruction, Optional<MemoryLocation>)
and delegating to the right ones, if we wanted to.
I have not attempted to do this yet.
Reviewers: dberlin, davide, dblaikie
Subscribers: sanjoy, hfinkel, chandlerc, llvm-commits
Differential Revision: https://reviews.llvm.org/D35441
llvm-svn: 309641
|
|
|
|
| |
llvm-svn: 309640
|
|
|
|
|
|
| |
DSO coverage may be dumped in any order.
llvm-svn: 309639
|
|
|
|
|
|
|
|
|
|
| |
Android uses libgcc name even for shared library unlike other platforms
which use libgcc_s. Furthemore, Android libstdc++ has a dependency on
libdl. These need to be handled while performing CMake checks.
Differential Revision: https://reviews.llvm.org/D36035
llvm-svn: 309638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reverting D36093 until I can figure out how to launch the correct tests :/
My apologies.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36120
llvm-svn: 309637
|
|
|
|
| |
llvm-svn: 309636
|
|
|
|
|
|
| |
Patch by Vlad Tsyrklevich!
llvm-svn: 309635
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add powerpc64 to compiler-rt build infrastructure.
Reviewers: timshen
Reviewed By: timshen
Subscribers: nemanjai, dberris, mgorny, aheejin, cfe-commits
Differential Revision: https://reviews.llvm.org/D36108
llvm-svn: 309634
|
|
|
|
|
|
|
|
|
|
| |
it is inferred from -isysroot.
This fixes a change that was inadvertently introduced in r309607.
rdar://problem/32230613
llvm-svn: 309633
|
|
|
|
|
|
| |
tables.
llvm-svn: 309632
|
|
|
|
|
|
|
|
|
|
|
| |
- Don't do any checks of the current SCM repository if the
llvm repositories are already there. Useful for bots.
- When symlinking, remove old symlinks.
- Support loading build-script as a library, not necessarily
under Xcode.
- Stringify args before passing them to subprocess.
llvm-svn: 309631
|
|
|
|
|
|
|
|
| |
Chromium's gold build seems to have trouble with this (gold produces
errors) - not sure if it's gold that's not coping with the valid
representation, or a bug in the implementation in LLVM, etc.
llvm-svn: 309630
|
|
|
|
|
|
|
|
| |
the number of check lines on some test cases.
This was pointed out during the review for D313804.
llvm-svn: 309629
|
|
|
|
|
|
|
|
|
|
| |
When the first instruction of a basic block has no location (consider a
LEA materializing the address of an alloca for a call), we want to start
the line table for the block with the first valid source location in the
block. We need to ignore DBG_VALUE instructions during this scan to get
decent line tables.
llvm-svn: 309628
|
|
|
|
| |
llvm-svn: 309627
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36106
llvm-svn: 309626
|
|
|
|
| |
llvm-svn: 309625
|
|
|
|
|
|
|
| |
Caused a bot test failure:
http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/5325
llvm-svn: 309624
|
|
|
|
|
|
| |
This will prevent me from introducing a regression in my next commit.
llvm-svn: 309623
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenFunction::EmitTypeMetadataCodeForVCall() could output an
llvm.assume(llvm.type.test())when CFI was enabled, optimizing out the
vcall check. This case was only reached when: 1) CFI-vcall was enabled,
2) -fwhole-program-tables was specified, and 3)
-fno-sanitize-trap=cfi-vcall was specified.
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D36013
llvm-svn: 309622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D33925 added a control flow simplification for -O2 --lto-O0 builds that
manually splits blocks and reassigns conditional branches but does not
correctly update phi nodes. If the else case being branched to had
incoming phi nodes the control-flow simplification would leave phi nodes
in that BB with an unhandled predecessor.
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D36012
llvm-svn: 309621
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36100
llvm-svn: 309620
|
|
|
|
|
|
|
|
|
| |
Windows/ARM64 is a LLP64 environment, so don't set this default
define.
Differential Revision: https://reviews.llvm.org/D36098
llvm-svn: 309619
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D36099
llvm-svn: 309618
|
|
|
|
|
|
|
|
| |
Patch by Vlad Tsyrklevich!
Differential Revision: https://reviews.llvm.org/D35855
llvm-svn: 309617
|
|
|
|
|
|
| |
A change to InstCombine broke this test, but we generally frown on running optimizations clang tests anyway. So I've updated the checks to not depend on optimizations anymore.
llvm-svn: 309616
|
|
|
|
|
|
| |
flags for one test (for now)
llvm-svn: 309615
|
|
|
|
|
|
|
| |
Fix for pr30418 - error in backend: Cannot select: t17: x86mmx = select_cc t2, Constant:i64<0>, t7, t8, seteq:ch
Differential Revision: https://reviews.llvm.org/D34661
llvm-svn: 309614
|
|
|
|
|
|
| |
The scalar transforms exist with no test coverage. The vector equivalents are missing.
llvm-svn: 309612
|
|
|
|
| |
llvm-svn: 309611
|
|
|
|
| |
llvm-svn: 309610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows -polly-optree to move instructions that depend on
synthesizable values.
The difficulty for synthesizable values is that their value depends on
the location. When it is moved over a loop header, and the SCEV
expression depends on the loop induction variable (SCEVAddRecExpr), it
would use the current induction variable instead of the last one.
At the moment we cannot forward PHI nodes such that crossing the header
of loops referenced by SCEVAddRecExpr is not possible (assuming the loop
header has at least two incoming blocks: for entering the loop and the
backedge, such any instruction to be forwarded must have a phi between
use and definition).
A remaining issue is when the forwarded value is used after the loop,
but is only synthesizable inside the loop. This happens e.g. if
ScalarEvolution is unable to determine the number of loop iterations or
the initial loop value. We do not forward in this situation.
Differential Revision: https://reviews.llvm.org/D36102
llvm-svn: 309609
|
|
|
|
|
|
|
|
|
|
| |
We don't write any actual symbols to this stream yet, but for
now we just create the stream and hook it up to the appropriate
places and give it a valid header.
Differential Revision: https://reviews.llvm.org/D35290
llvm-svn: 309608
|
|
|
|
|
|
|
|
|
|
| |
deployment target is earlier than iOS 11 and the target is 32-bit.
This is a follow-up to r306922.
rdar://problem/32230613
llvm-svn: 309607
|
|
|
|
|
|
|
| |
GCC was complaining about `&&` within `||` without explicit
parentheses. NFCI.
llvm-svn: 309606
|
|
|
|
|
|
|
|
| |
Before we were doing it with --export-dynamic. That seems incorrect.
The intention of --export-dynamic is to export symbols *defined* in
the executable.
llvm-svn: 309605
|
|
|
|
|
|
|
|
|
|
| |
This intrinsic clears the upper bits starting at a specified index. If the index is a constant we can do some simplifications.
This could be in InstSimplify, but we don't handle any target specific intrinsics there today.
Differential Revision: https://reviews.llvm.org/D36069
llvm-svn: 309604
|