This fixes parsing of forward references to unnamed aliases.
While here, remove an unnecessary isa check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254054 91177308-0d34-0410-b5e6-96231b3b80d8
The main motivation is to not require a latex installation when building
the documentation. I would also expect a better image quality and the
ability to copy&paste from formulas with a javascript based solution for
displaying the math.
Differential Revision: http://reviews.llvm.org/D14960
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254048 91177308-0d34-0410-b5e6-96231b3b80d8
This caused PR25607 and also caused Chromium to crash on start-up.
(Also had to update test/CodeGen/X86/avx-splat.ll, which was committed
after shrink wrapping was enabled.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254044 91177308-0d34-0410-b5e6-96231b3b80d8
Add a simple initial heuristic to control importing based on the number
of instructions recorded in the function's summary. Add option to
control the limit, and test using option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254036 91177308-0d34-0410-b5e6-96231b3b80d8
When the original binary is executed and sampled, the resulting profile
contains information on the original inline stack. We currently follow
the original inline plan if we notice that the inlined callsite has more
than 0 samples to it.
A better way is to determine whether the callsite is actually worth
inlining. If the callsite accumulates a small fraction of the samples
spent in the parent function, then we don't want to bother inlining it
(as it means that the callsite is actually cold).
This patch introduces a threshold expressed in percentage of samples
in relation to the parent function. If the callsite uses less than N%
of the total samples used by its parent, the original inline decision is
not re-applied.
I've set the threshold to the very arbitrary value of 5%. I'm yet to do
any actual experiments to see what's a good value. I wanted to separate
the basic mechanism from the tuning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254034 91177308-0d34-0410-b5e6-96231b3b80d8
Change origin-alignment test to test only the alignment of the origin
store, and not the exact instruction sequence used to compute the
address. This makes the test less fragile and, in particular, lets it
pass both with the old and new MSan ABIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254027 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements a minimum spanning tree (MST) based instrumentation for
PGO. The use of MST guarantees minimum number of CFG edges getting
instrumented. An addition optimization is to instrument the less executed
edges to further reduce the instrumentation overhead. The patch contains both the
instrumentation and the use of the profile to set the branch weights.
Differential Revision: http://reviews.llvm.org/D12781
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254021 91177308-0d34-0410-b5e6-96231b3b80d8
Consolidate the description of -binary/-text option description
to avoid duplicate ID error by sphinux-build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254018 91177308-0d34-0410-b5e6-96231b3b80d8
r253918 had refactored expressions like "A - B.Address + C" to "A -
B.getAddressWithOffset(C)". This is incorrect, since the latter really
computes "A - B.Address - C".
None of the tests I can run locally on x86 broke due to this bug, but it
is the current suspect for breakage on the AArch64 buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254017 91177308-0d34-0410-b5e6-96231b3b80d8
X86 needs to use its own FMA opcodes, preventing the standard FNEG(FMA) pattern table recognition method used by other platforms. This patch adds support for lowering FNEG(FMA(X,Y,Z)) into a single suitably negated FMA instruction.
Fix for PR24364
Differential Revision: http://reviews.llvm.org/D14906
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254016 91177308-0d34-0410-b5e6-96231b3b80d8
Analyze imported function bodies and add any new external calls to
the worklist for importing. Currently no controls on the importing
so this will end up importing everything possible in the call tree
below the importing module. Basic profitability checks coming next.
Update test to check for iteratively inlined functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254011 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the following issues:
1. Fix the return type of X86psadbw: it should not be the same type of inputs.
For vNi8 inputs the output should be vMi64, where M = N/8.
2. Fix the return type of int_x86_avx512_psad_bw_512 accordingly.
3. Fix the definiton of PSADBW, VPSADBW, and VPSADBWY accordingly.
4. Adjust the return type when building a DAG node of X86ISD::PSADBW type.
5. Update related tests.
Differential revision: http://reviews.llvm.org/D14897
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254010 91177308-0d34-0410-b5e6-96231b3b80d8
The new function import pass exposed an issue when we import references
to local values on multiple importing passes. They are renamed on each
import pass, and we need to ensure that the already promoted and renamed
references existing in the dest module are correctly identified and
updated so that they aren't spuriously renamed again (due to a perceived
conflict with the newly linked reference).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254009 91177308-0d34-0410-b5e6-96231b3b80d8
The closure is designed to abstact away two types of value profile
data:
- InstrProfRecord which is the primary data structure used to
represent profile data in host tools (reader, writer, and profile-use)
- value profile runtime data structure suitable to be used by C
runtime library.
Both sources of data need to serialize to disk/memory-buffer in common
format: ValueProfData.
The abstraction allows compiler-rt's raw profiler writer to share
the same code with indexed profile writer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@254008 91177308-0d34-0410-b5e6-96231b3b80d8
Convert two C++ static member functions to be C APIs. This
is one of the many steps to get ready to share VP writer code
with profiler runtime.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253999 91177308-0d34-0410-b5e6-96231b3b80d8
Skip imports for weak_any aliases as well. Fix the test to check
non-import of weak aliases and functions, and import of normal alias.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253991 91177308-0d34-0410-b5e6-96231b3b80d8
We had duplicated definitions for the same hardware '[v]movq' instructions. For example with SSE:
def MOVZQI2PQIrr : RS2I<0x6E, MRMSrcReg, (outs VR128:$dst), (ins GR64:$src),
"mov{d|q}\t{$src, $dst|$dst, $src}", // X86-64 only
[(set VR128:$dst, (v2i64 (X86vzmovl (v2i64 (scalar_to_vector GR64:$src)))))],
IIC_SSE_MOVDQ>;
def MOV64toPQIrr : RS2I<0x6E, MRMSrcReg, (outs VR128:$dst), (ins GR64:$src),
"mov{d|q}\t{$src, $dst|$dst, $src}",
[(set VR128:$dst, (v2i64 (scalar_to_vector GR64:$src)))],
IIC_SSE_MOVDQ>, Sched<[WriteMove]>;
As shown in the test case and PR25554:
https://llvm.org/bugs/show_bug.cgi?id=25554
This causes us to miss reusing an operand because later passes don't know these 'movq' are the same instruction.
This patch deletes one pair of these defs.
Sadly, this won't fix the original test case in the bug report. Something else is still broken.
Differential Revision: http://reviews.llvm.org/D14941
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253988 91177308-0d34-0410-b5e6-96231b3b80d8
This tests that a declaration can resolve to an alias.
I broke this locally while prototyping a change and it looks like a nice
test to have.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253984 91177308-0d34-0410-b5e6-96231b3b80d8
The one regression in the builtin tests is in the read2 test which now
(again) has many extra copies, but this should be solved once the pass
is replaced with a DAG combine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253974 91177308-0d34-0410-b5e6-96231b3b80d8
CMAKE_EXE_LINKER_FLAGS is a string. Appending a flag using list(APPEND) introduces an extra
semicolon which breaks stuff. Change this to append the value in the same way that everyone else
seems to be doing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253968 91177308-0d34-0410-b5e6-96231b3b80d8
The patch in http://reviews.llvm.org/D13745 is broken into four parts:
1. New interfaces without functional changes.
2. Use new interfaces in SelectionDAG, while in other passes treat probabilities
as weights.
3. Use new interfaces in all other passes.
4. Remove old interfaces.
This the second patch above. In this patch SelectionDAG starts to use
probability-based interfaces in MBB to add successors but other MC passes are
still using weight-based interfaces. Therefore, we need to maintain correct
weight list in MBB even when probability-based interfaces are used. This is
done by updating weight list in probability-based interfaces by treating the
numerator of probabilities as weights. This change affects many test cases
that check successor weight values. I will update those test cases once this
patch looks good to you.
Differential revision: http://reviews.llvm.org/D14361
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253965 91177308-0d34-0410-b5e6-96231b3b80d8
