| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would assert that the FP setup CFI used esp/rsp always. This held up in
practice when the code was generated from IR. However, with the integrated
assembler, it is possible to have the input be user specified assembly. In such
a case, we cannot assume that the function implementation has a compact unwind
representation. Loosen the assertion into a check and bail if we cannot
represent the frame pointer in the compact unwinding.
Addresses PR30453!
llvm-svn: 281986
|
|
|
|
|
|
|
|
| |
to the TLOF mach-o version.
NFC intended.
llvm-svn: 281983
|
|
|
|
|
|
|
|
| |
rid of the default subtarget.
NFC intended.
llvm-svn: 281982
|
|
|
|
|
|
| |
inline the result into the singular caller.
llvm-svn: 281981
|
|
|
|
|
|
| |
Include header messages and remove unnecessary blank lines.
llvm-svn: 281980
|
|
|
|
|
|
|
|
|
|
|
| |
This should match the existing behaviour for passing complicated struct and
array types, in particular HFAs come through like that from Clang.
For C & C++ we still need to somehow support all the weird ABI flags, or at
least those that are present in the IR (signext, byval, ...), and stack-based
parameter passing.
llvm-svn: 281977
|
|
|
|
| |
llvm-svn: 281972
|
|
|
|
|
|
|
|
| |
The generated code is still not optimal.
Differential Revision: https://reviews.llvm.org/D24723
llvm-svn: 281966
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D24664
llvm-svn: 281965
|
|
|
|
|
|
|
|
|
|
| |
The routines llvm::ConvertDebugDeclareToDebugValue() always returned
a true value which was never checked at the call site; change the
function return type to void.
This NFC cleanup was approved in the review https://reviews.llvm.org/D23715
llvm-svn: 281964
|
|
|
|
| |
llvm-svn: 281961
|
|
|
|
|
|
|
|
|
|
|
|
| |
SROA doesn't preserve the llvm.mem.parallel_loop_access metadata when it
transforms loads/stores. This patch fixes a couple occurences of this
issue.
(Partially addresses PR28981).
Differential Revision: https://reviews.llvm.org/D23549
llvm-svn: 281960
|
|
|
|
|
|
|
|
| |
XMM16-XMM31 or YMM16-YMM31 are the source or dest of the copy and VLX is not supported.
This can happen with SUBREG_TO_REG of ZMM16-ZMM31. Fixes PR30430.
llvm-svn: 281959
|
|
|
|
|
|
|
|
| |
when F16C and VLX are not supported.
Fixes PR23941.
llvm-svn: 281958
|
|
|
|
|
|
|
|
|
|
| |
It is legal to merge instructions with different undef flags; However we
must drop the undef flag from the merged instruction if it isn't present
everywhere.
This fixes http://llvm.org/PR30199
llvm-svn: 281957
|
|
|
|
| |
llvm-svn: 281953
|
|
|
|
| |
llvm-svn: 281952
|
|
|
|
|
|
|
|
|
|
| |
When looking at the scribus_1.3 example from https://llvm.org/bugs/show_bug.cgi?id=10584, I noticed that we were spending a large amount of time computing loop exits in LCSSA. This code appears to be written with the assumption that LoopExits are stored in the Loop and thus cheap to query. This is not true, so we should cache the result across the potentially long running loop which tends to visit a small handful of Loops.
On the particular example from 10584, this change drops the time spent in LCSSA computation by about 80%.
Differential Revision: https://reviews.llvm.org/D24509
llvm-svn: 281949
|
|
|
|
|
|
| |
This was meant to be commited with my previous commit.
llvm-svn: 281948
|
|
|
|
| |
llvm-svn: 281947
|
|
|
|
| |
llvm-svn: 281944
|
|
|
|
|
|
| |
operand bundles
llvm-svn: 281940
|
|
|
|
|
|
| |
coverage from instrumented libc++
llvm-svn: 281933
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Callsites in the same basic block should share the same hotness. This patch checks for the hottest callsite in the same basic block, and use the hotness for all callsites in that basic block for early inline decisions. It also fixes the test to add "-S" so theat the "CHECK-NOT" is actually checking the content.
Reviewers: dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24734
llvm-svn: 281927
|
|
|
|
|
|
|
|
|
|
|
| |
The OperandsMapper class is used heavy in RegBankSelect and each
instantiation triggered a heap allocation for the array of operands.
Instead, use a SmallVector with a big enough size such that most of the
cases do not have to use dynamically allocated memory.
This improves the compile time of the RegBankSelect pass.
llvm-svn: 281916
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Machine programs need a definition of each vreg before reaching a use
(the definition may come from an IMPLICIT_DEF instruction). This class
of errors is not detected by the MachineVerifier because of efficiency
concerns. LiveRangeCalc used to report these problems, make it do that
again (followup to r279625).
Also use report_fatal_error() instead of llvm_unreachable() as the error
reporting is only present in asserts build anyway.
llvm-svn: 281914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
branch is non-zero. Otherwise use default static profile to set branch probability.
Summary: It does not make sense to set equal weights for all unkown branches as we have static branch prediction available.
Reviewers: dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24732
llvm-svn: 281912
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The call target count profile is directly derived from LBR branch->target data. This is more reliable than instruction frequency profiles that could be moved across basic block boundaries. This patches uses call target count profile to annotate call instructions.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24410
llvm-svn: 281911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is adding the support for a shadow memory with
dynamically allocated address range.
The compiler-rt needs to export a symbol containing the shadow
memory range.
This is required to support ASAN on windows 64-bits.
Reviewers: kcc, rnk, vitalybuka
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23354
llvm-svn: 281908
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24546
llvm-svn: 281903
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever an add/sub immediate needs a fixup, we set that immediate field to zero,
which is correct, but we also set the shift bits to zero, which is not true for
instructions that use lsl #12. This patch makes sure that if lsl #12 was used,
it will appear in the encoding of the instruction.
Differential Revision: https://reviews.llvm.org/D23930
llvm-svn: 281898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In case s_branch instruction target is itself backend should emit offset -1 but instead it emit 0.
'''
label:
s_branch label // should emit [0xff,0xff,0x82,0xbf]
'''
Tom, Matt: why are we adjusting fixup values in applyFixup() method instead of processFixup()? processFixup() is calling adjustFixupValue() but does nothing with its result.
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl
Differential Revision: https://reviews.llvm.org/D24671
llvm-svn: 281896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When phi nodes are created in the -mem2reg phase, the @llvm.dbg.declare
entries are converted to @llvm.dbg.value entries at the place where the
store instructions existed. However no entry is created to describe
the resulting value of the phi node.
The effect of this is especially noticeable in for loops which have a
constant for the intial value; the loop control variable's location
would be described as the intial constant value in the loop body once
the -mem2reg optimization phase was run.
This change adds the creation of the @llvm.dbg.value entries to describe
variables whose location is the result of a phi node created in -mem2reg.
Also when the phi node is finally lowered to a machine instruction it
is important that the lowered "load" instruction is placed before the
associated DEBUG_VALUE entry describing the value loaded.
Differential Revision: https://reviews.llvm.org/D23715
llvm-svn: 281895
|
|
|
|
|
|
|
|
|
|
| |
The initial mapping symbol state is set from the triple, but we only checked
for the little-endian thumb triple, so could end up with an ARM mapping symbol
for big-endian thumb.
Differential Revision: https://reviews.llvm.org/D24553
llvm-svn: 281894
|
|
|
|
|
|
|
|
|
| |
ldm and stm instructions always require 4-byte alignment on the pointer, but we
weren't checking this before trying to reduce code-size by replacing a
post-indexed load/store with them. Unfortunately, we were also dropping this
incormation in DAG ISel too, but that's easy enough to fix.
llvm-svn: 281893
|
|
|
|
|
|
|
|
| |
We were updating metadata but not IR flags. Because we pick an arbitrary instruction to be the CSE candidate, it comes down to luck (50% or less chance) if this results in broken codegen or not, which is why PR30373 which is actually not the fault of the commit it was bisected down to.
Fixes PR30373.
llvm-svn: 281889
|
|
|
|
|
|
|
|
| |
not the output of an instruction.
SUBREG_TO_REG is supposed to indicate that the super register has been zeroed, but we can't prove that if we don't know where it came from.
llvm-svn: 281885
|
|
|
|
|
|
|
|
| |
supported regardless of whether F16C is also supported.
Still need to add support for lowering using AVX512F when neither VLX or F16C is supported.
llvm-svn: 281884
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a port of XRay to ARM 32-bit, without Thumb support yet. The XRay instrumentation support is moving up to AsmPrinter.
This is one of 3 commits to different repositories of XRay ARM port. The other 2 are:
https://reviews.llvm.org/D23932 (Clang test)
https://reviews.llvm.org/D23933 (compiler-rt)
Differential Revision: https://reviews.llvm.org/D23931
llvm-svn: 281878
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previously we reline on inst-combine to remove inlinable invoke instructions. This causes trouble because a few extra optimizations are schedule early that could introduce too much CFG change (e.g. simplifycfg removes too much control flow). This patch handles invoke instruction in-place during sample profile annotation, so that we do not rely on instcombine to remove those invoke instructions.
Reviewers: davidxl, dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24409
llvm-svn: 281870
|
|
|
|
|
|
|
|
| |
rounding mode encoding in the second operand. This immediate should only be 0 or 1 and indicates if the truncation loses precision.
Also enhance an assert in SelectionDAG::getNode to flag this sort of problem in the future.
llvm-svn: 281868
|
|
|
|
|
|
| |
second operand containing an X86 specific rounding mode encoding that doesn't belong.
llvm-svn: 281867
|
|
|
|
|
|
| |
libFuzzer
llvm-svn: 281866
|
|
|
|
| |
llvm-svn: 281865
|
|
|
|
| |
llvm-svn: 281862
|
|
|
|
|
|
| |
conversion intrinsics to be consistent across all intruction sets.
llvm-svn: 281861
|
|
|
|
|
|
| |
correct register class.
llvm-svn: 281860
|
|
|
|
| |
llvm-svn: 281859
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23727
llvm-svn: 281858
|
|
|
|
|
|
|
|
|
| |
Amended consecutive memory access detection in Loop Vectorizer.
Load/Store were not handled properly without preceding GEP instruction.
Differential Revision: https://reviews.llvm.org/D20789
llvm-svn: 281853
|