| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
The right way to parse arch names is by creating a triple. This was
using getArchTypeForLLVMName before, which doesn't really do the right
thing here.
llvm-svn: 315965
|
| |
|
|
|
|
|
|
|
|
|
| |
We want to be writing a 32bit value, so we should be writing 4 bytes
instead of 2.
Patch by Alex Langford <apl@fb.com>.
Differential Revision: https://reviews.llvm.org/D38872
llvm-svn: 315964
|
| |
|
|
|
|
|
|
|
| |
In r315960, I accidentally assumed that the first line segment is
guaranteed to be the non-gap region entry segment (given that one is
present). It can actually be any segment on the line, and the test I
checked in demonstrates that.
llvm-svn: 315963
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r315713. It causes PR34968.
I think I know what the problem is, but I don't think I'll have time to fix it
this week.
llvm-svn: 315962
|
| |
|
|
| |
llvm-svn: 315961
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Gap areas make it possible to correctly determine when to use counts
from deferred regions. Before gap areas were introduced, llvm-cov needed
to use a heuristic to do this: it ignored counts from segments that
start, but do not end, on a line. This heuristic breaks down on a simple
example (see PR34962).
This patch removes the heuristic and picks counts from any region entry
segment which isn't a gap area.
llvm-svn: 315960
|
| |
|
|
|
|
|
|
| |
UpdateNodeOperands() modifies the node in-place and using the return value isn’t strictly necessary. However, it does not necessarily modify the node, but may return a resultant node if it already exists in the DAG. See comments in UpdateNodeOperands(). In that case, the return value must be used to avoid such scenarios as an infinite loop (node is assumed to have been updated, so added back to the worklist, and re-processed; however, node hasn’t changed so it is once again passed to UpdateNodeOperands(), assumed modified, added back to worklist; cycle infinitely repeats).
Differential Revision: https://reviews.llvm.org/D38466
llvm-svn: 315957
|
| |
|
|
| |
llvm-svn: 315955
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We add /usr/local/include to the include directory list for some BSD
systems. We should mark this as a system directory to avoid files from
/usr/local/include getting picked over files shipping with llvm.
This typically manifested as gtest headers installed with the system
getting picked over the ones shipping with llvm.
Patch by Petr Penzin <penzin.dev@gmail.com>
Differential Revision: https://reviews.llvm.org/D37415
llvm-svn: 315952
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for COPY
This reverts commit r315823, thus re-applying r315781.
Also make sure we don't use G_BITCAST mapping for non-generic registers.
Non-generic registers don't have a type but do have a reg bank.
Something the COPY mapping now how to deal with but the G_BITCAST
mapping don't.
-- Original Commit Message --
We use to resort on the generic implementation to get the mappings for
COPYs. The generic implementation resorts on table lookup and
dynamically allocated objects to get the valid mappings.
Given we already know how to map G_BITCAST and have the static mappings
for them, use that code path for COPY as well. This is much more
efficient.
Improve the compile time of RegBankSelect by up to 20%.
Note: When we eventually generate all the mappings via TableGen, we
wouldn't have to do that dance to shave compile time. The intent of this
change was to make sure that moving to static structure really pays off.
NFC.
llvm-svn: 315947
|
| |
|
|
|
|
| |
Anything bigger than 64-bit just map to FPR.
llvm-svn: 315946
|
| |
|
|
|
|
|
| |
We used to mark all G_BITCAST of 128-bit legal but only for vector
types. Scalars of this size are just fine as well.
llvm-svn: 315945
|
| |
|
|
|
|
|
|
|
| |
This patch adds a new kind of metadata that indicates the possible callees of
indirect calls.
Differential Revision: https://reviews.llvm.org/D37354
llvm-svn: 315944
|
| |
|
|
|
|
|
|
|
|
| |
This will prevent doubling of line endings when parsing assembly and
emitting assembly.
Otherwise we'd parse the directive, consume the end of statement, hit
the next end of statement, and emit a fresh newline.
llvm-svn: 315943
|
| |
|
|
| |
llvm-svn: 315942
|
| |
|
|
|
|
| |
usage. NFCI
llvm-svn: 315941
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 315940
|
| |
|
|
| |
llvm-svn: 315939
|
| |
|
|
| |
llvm-svn: 315938
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Code is already in compiler-rt
Reviewers: kcc
Subscribers: krytarowski, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D38912
llvm-svn: 315937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(OpenCL example):
static __global int Var = 0;
__global int* Ptr[] = {&Var};
...
In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.
Differential Revision: https://reviews.llvm.org/D38909
llvm-svn: 315935
|
| |
|
|
|
|
| |
(according to the contract)
llvm-svn: 315933
|
| |
|
|
|
|
| |
instantiates addPredicate out of line
llvm-svn: 315932
|
| |
|
|
|
|
|
| |
MSVC doesn't seem to like implicitly instantiating addPredicate and then
explicitly specializing it later. It causes an internal compiler error.
llvm-svn: 315930
|
| |
|
|
| |
llvm-svn: 315927
|
| |
|
|
|
|
| |
Recommit r315763 with a fix.
llvm-svn: 315925
|
| |
|
|
|
|
| |
Post commit review comments at D38825.
llvm-svn: 315920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the ability to perform IPSCCP-like interprocedural analysis to
the generic sparse propagation solver. The patch gives clients the ability to
define their own custom LatticeKey types that the generic solver maps to custom
LatticeVal types. The custom lattice keys can be used, for example, to
distinguish among mappings for regular values, values returned from functions,
and values stored in global variables. Clients are responsible for defining how
to convert between LatticeKeys and LLVM Values by providing a specialization of
the LatticeKeyInfo template.
The added unit tests demonstrate how the generic solver can be used to perform
a simplified version of interprocedural constant propagation.
Differential Revision: https://reviews.llvm.org/D37353
llvm-svn: 315919
|
| |
|
|
| |
llvm-svn: 315916
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
above PHI instructions.
ARC optimizer has an optimization that moves a call to an ObjC runtime
function above a phi instruction when the phi has a null operand and is
an argument passed to the function call. This optimization should not
kick in when the runtime function is an objc_release that releases an
object with precise lifetime semantics.
rdar://problem/34959669
llvm-svn: 315914
|
| |
|
|
| |
llvm-svn: 315913
|
| |
|
|
| |
llvm-svn: 315911
|
| |
|
|
| |
llvm-svn: 315910
|
| |
|
|
| |
llvm-svn: 315909
|
| |
|
|
|
|
|
|
| |
dead one
Differential revision: https://reviews.llvm.org/D38754
llvm-svn: 315908
|
| |
|
|
| |
llvm-svn: 315907
|
| |
|
|
|
|
| |
Mainly inspired by PR34773
llvm-svn: 315906
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously these instructions were marked codegen only and had
an under-specified instruction description that did not record the
fcc register.
Reviewers: atanasyan, abeserminji
Differential Revision: https://reviews.llvm.org/D38847
llvm-svn: 315905
|
| |
|
|
|
|
|
|
|
|
|
| |
Minor addition and follow up of r314773 and r311533: this adds more
debug messages to the type legalizer. For each node, it dumps
legalization info for results and operands nodes, rather than just the
final legalized node.
Differential Revision: https://reviews.llvm.org/D38726
llvm-svn: 315904
|
| |
|
|
| |
llvm-svn: 315903
|
| |
|
|
|
|
|
| |
Ordering of patterns should not be of importance anymore
since the predicates used are mutually exclusive now.
llvm-svn: 315901
|
| |
|
|
|
|
| |
This patch fixes a potential problem in my previous commit (https://reviews.llvm.org/rL315888) by adding a null check.
llvm-svn: 315900
|
| |
|
|
|
|
| |
PR7709, PR17697, PR19251, PR32809 and PR21640. There could be other bugs closed by this patch.
llvm-svn: 315899
|
| |
|
|
|
|
|
|
|
| |
Currently llvm-dwarfdump runs into llvm_unreachable when
faces DW_CFA_GNU_args_size. Patch implements the support.
Differential revision: https://reviews.llvm.org/D38879
llvm-svn: 315897
|
| |
|
|
|
|
| |
(D38586)"
llvm-svn: 315896
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The following transformation for cmp instruction:
icmp smin(x, PositiveValue), 0 -> icmp x, 0
should only be done after checking for min/max to prevent infinite
looping caused by a reverse canonicalization. That is why this
transformation was moved to place after the mentioned check.
Reviewers: spatel, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38934
Patch by: Artur Gainullin <artur.gainullin@intel.com>
llvm-svn: 315895
|
| |
|
|
| |
llvm-svn: 315894
|
| |
|
|
| |
llvm-svn: 315891
|
| |
|
|
|
|
|
|
|
|
| |
incorrect G_FRAME_INDEX handling
The wrong operand was being rendered to the result instruction.
The crash was detected by Bitcode/simd_ops/AArch64_halide_runtime.bc
llvm-svn: 315890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We came across an llvm bug when compiling some testcases that 64-bit
immediates are silently truncated into 32-bit and then packed into
BPF_JMP | BPF_K encoding. This caused comparison with wrong value.
This bug looks to be introduced by r308080. The Select_Ri pattern is
supposed to be lowered into J*_Ri while the latter only support 32-bit
immediate encoding, therefore Select_Ri should have similar immediate
predicate check as what J*_Ri are doing.
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Reviewed-by: Yonghong Song <yhs@fb.com>
llvm-svn: 315889
|