Immediates can be folded as long as the immediate is a vreg.
Also undo commuting instructions if it didn't fold an immediate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307575 91177308-0d34-0410-b5e6-96231b3b80d8
An instruction that has an immediate operand can't reach
this point. This is only called for a freshly shrunk instruction,
which prevously couldn't have had a literal constant operand.
This was also not conservative enough since it woudl also have
had to filter other constant-like inputs like frame indexes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307574 91177308-0d34-0410-b5e6-96231b3b80d8
Many of the test cases in the runtimes require LLVM's testing tools, to
facilitate this working as expected we need to have all the test targets
in the runtimes depend on all LLVM testing tools used in the runtimes.
Differential Revision: https://reviews.llvm.org/D33048
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307572 91177308-0d34-0410-b5e6-96231b3b80d8
This was originally reverted because of two issues.
1) Printing ANSI color escape codes even when outputting to
a file
2) Module name comparisons were failing when comparing a PDB
generated on one machine to a PDB generated on another
machine.
I attempted to fix#2 by adding command line options which let
you specify prefixes to strip from the beginning of embedded
paths, which effectively lets us specify a path to "base" each
PDB from and only compare the parts under the base. But this is
tricky because PDB paths always use Windows path syntax, even
when they are created on non-Windows hosts. A problem still
existed when constructing the prefix to strip, where we were
accidentally using a host-specific path separator instead of
a Windows path separator.
This resubmission fixes the issue on Linux (and I have verified
that the test now passes on Linux).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307571 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 180af3fdbdb17ec35b45ec1f925fd743b28d37e1.
This is still breaking due to linux-specific path differences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307559 91177308-0d34-0410-b5e6-96231b3b80d8
A test was checked in on Friday that worked by checking in an
object file and PDB generated locally by MSVC, and then having
the test run lld-link on the object file and diffing LLD's PDB
against the checked in PDB.
This failed because part of the diffing algorithm involves
determining if two modules are the same, and if so drilling into
the module and diffing individual fields of the module. The
only thing we can use to make this determination though is the
"name" of the module, which is a path to where the module (obj
file) was read from on the machine where it was linked. This
fails for obvious reasons when comparing a PDB generated on one
machine to a PDB on another machine.
The fix employed here is to add two command line options to the
diff subcommand, which allow the user to specify a "binary root
path". The bin root path, if specified, is stripped from the
beginning of any embedded PDB paths. The test is updated to
specify the user's local test output directory for the left
PDB, and is hardcoded to the location where the original PDB
was created for the right PDB. This way all the equivalence
comparisons should succeed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307555 91177308-0d34-0410-b5e6-96231b3b80d8
Memory accesses offset from frame indices may alias, e.g., we
may merge write from function arguments passed on the stack when they
are contiguous. As a result, when checking aliasing, we consider the
underlying frame index's offset from the stack pointer.
Static allocs are realized as stack objects in SelectionDAG, but its
offset is not set until post-DAG causing DAGCombiner's alias check to
consider access to static allocas to frequently alias. Modify isAlias
to consider access between static allocas and access from other frame
objects to be considered aliasing.
Many test changes are included here. Most are fixes for tests which
indirectly relied on our aliasing ability and needed to be modified to
preserve their original intent.
The remaining tests have minor improvements due to relaxed
ordering. The exception is CodeGen/X86/2011-10-19-widen_vselect.ll
which has a minor degradation dispite though the pre-legalized DAG is
improved.
Reviewers: rnk, mkuper, jonpa, hfinkel, uweigand
Reviewed By: rnk
Subscribers: sdardis, nemanjai, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307546 91177308-0d34-0410-b5e6-96231b3b80d8
When unrolling under multiple exits which is under off-by-default option,
the assert that checks for VMap entry in loop exit values is too strong.
(assert if VMap entry did not exist, the value should be a
constant). However, values derived from
constants or from values outside loop, does not have a VMap entry too.
Removed the assert and added a testcase showcasing the property for
non-constant values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307542 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds a callback registration API to the PassBuilder,
enabling registering out-of-tree passes with it.
Through the Callback API, callers may register callbacks with the
various stages at which passes are added into pass managers, including
parsing of a pass pipeline as well as at extension points within the
default -O pipelines.
Registering utilities like `require<>` and `invalidate<>` needs to be
handled manually by the caller, but a helper is provided.
Additionally, adding passes at pipeline extension points is exposed
through the opt tool. This patch adds a `-passes-ep-X` commandline
option for every extension point X, which opt parses into pipelines
inserted into that extension point.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33464
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307532 91177308-0d34-0410-b5e6-96231b3b80d8
Variable was called 'Name' and contained text
name of relocation type. Problem was that
outside of this error handling scope we already
have different 'Name' variable that contains
section name.
Change helps to avoid confusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307530 91177308-0d34-0410-b5e6-96231b3b80d8
The SandyBridge architects have provided us with a more accurate information about each instruction latency, number of uOPs and used ports and I used it to replace the existing estimated SNB instructions scheduling and to add missing scheduling information.
Please note that the patch extensively affects the X86 MC instr scheduling for SNB.
Also note that this patch will be followed by additional patches for the remaining target architectures HSW, IVB, BDW, SKL and SKX.
The updated and extended information about each instruction includes the following details:
•static latency of the instruction
•number of uOps from which the instruction consists of
•all ports used by the instruction's' uOPs
For example, the following code dictates that instructions, ADC64mr, ADC8mr, SBB64mr, SBB8mr have a static latency of 9 cycles. Each of these instructions is decoded into 6 micro operations which use ports 4, ports 2 or 3 and port 0 and ports 0 or 1 or 5:
def SBWriteResGroup94 : SchedWriteRes<[SBPort4,SBPort23,SBPort0,SBPort015]> {
let Latency = 9;
let NumMicroOps = 6;
let ResourceCycles = [1,2,2,1];
}
def: InstRW<[SBWriteResGroup94], (instregex "ADC64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "ADC8mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB64mr")>;
def: InstRW<[SBWriteResGroup94], (instregex "SBB8mr")>;
Note that apart for the header, most of the X86SchedSandyBridge.td file was generated by a script.
Reviewers: zvi, chandlerc, RKSimon, m_zuckerman, craig.topper, igorb
Differential Revision: https://reviews.llvm.org/D35019#inline-304691
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307529 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Mark G_ZEXT/G_SEXT i1 to i8/i16, i8 to i16 as legal.
Support G_ZEXT i1 to i8/i16 instruction selection ( C++ code).
This patch requred to support G_LOAD/G_STORE i1.
Reviewers: zvi, guyblank
Reviewed By: guyblank
Subscribers: rovka, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35177
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307526 91177308-0d34-0410-b5e6-96231b3b80d8
r274441 introduced Chapter 10 of "Implementing a Language with LLVM" tutorial,
which caused all files in the tutorial to start using two digit numbering. But
many links were not changed and therefore appear to be broken. This patch
addresses described issue.
As a result, following command does not produce any output anymore:
$ grep -nR '<LangImpl[0-9].html>' ./docs/tutorial/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307525 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This solves PR33641.
When removing a dead argument we must also handle possibly existing calls
to llvm.dbg.value that use the removed argument. Now we change the use
of the otherwise dead argument to an undef for some other pass to cleanup
later.
If the calls are left untouched, they will later on cause errors:
"function-local metadata used in wrong function"
since the ArgumentPromotion rewrites the code by creating a new function
with the wanted signature, but the metadata is not recreated so the new
function may then erroneously use metadata from the old function.
Reviewers: mstorsjo, rnk, arsenm
Reviewed By: rnk
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D34874
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307521 91177308-0d34-0410-b5e6-96231b3b80d8
These asserts could only occur if we fail to properly detect the compiler, but an assert is not a good way to do that because it doesn't work in release builds.
I wonder if we could use #error?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307520 91177308-0d34-0410-b5e6-96231b3b80d8
Reduces llvm-profdata memory usage on a large profile from 7.8GB to 5.1GB.
The ProfData API now supports reporting all the errors/warnings rather
than only the first, though llvm-profdata ignores everything after the
first for now to preserve existing behavior. (if there's a desire for
other behavior, happy to implement that - but might be as well left for
a separate patch)
Reviewers: davidxl
Differential Revision: https://reviews.llvm.org/D35149
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307516 91177308-0d34-0410-b5e6-96231b3b80d8
WidenVSELECTAndMask can fold (and it folds in this case) so we
get a BUILD_VECTOR of constants as mask. convertMask() seems to
work fine when the input is a vector of constants, and we still
need to call it to extend/add elements at the end. but the current
code just asserts on anything but a SETCC or AND/OR/XOR of 2xSETCC.
This change was discussed briefly with Simon Pilgrim, who also
suggests we might consider dropping this assertion in the future.
Fixes PR33715.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307508 91177308-0d34-0410-b5e6-96231b3b80d8
This change fixes a bug in SelectionDAGBuilder::visitInsertValue and SelectionDAGBuilder::visitExtractValue where constant expressions (InsertValueConstantExpr and ExtractValueConstantExpr) would be treated as non-constant instructions (InsertValueInst and ExtractValueInst). This bug resulted in an incorrect memory access, which manifested as an assertion failure in SDValue::SDValue.
Fixes PR#33094.
Submitted on behalf of @Praetonus (Benoit Vey)
Differential Revision: https://reviews.llvm.org/D34538
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307502 91177308-0d34-0410-b5e6-96231b3b80d8
invalidation of analyses when merging SCCs.
While I've added a bunch of testing of this, it takes something much
more like the inliner to really trigger this as you need to have
partially-analyzed SCCs with updates at just the right time. So I've
added a direct test for this using the inliner and verifying the
domtree. Without the changes here, this test ends up finding a stale
dominator tree.
However, to handle this properly, we need to invalidate analyses
*before* merging the SCCs. After talking to Philip and Sanjoy about this
they convinced me this was the right approach. To do this, we need
a callback mechanism when merging SCCs so we can observe the cycle that
will be merged before the merge happens. This API update ended up being
surprisingly easy.
With this commit, the new PM passes the test-suite again. It hadn't
since MemorySSA was enabled for EarlyCSE as that also will find this bug
very quickly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307498 91177308-0d34-0410-b5e6-96231b3b80d8
dependencies between analyses.
This uncovers even more issues with the proxies and the splitting apart
of SCCs which are fixed in this patch. I discovered this while trying to
add more rigorous testing for a change I'm making to the call graph
update invalidation logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307497 91177308-0d34-0410-b5e6-96231b3b80d8
by a valid octal digit.
The length argument shows that this was in fact the intent.
This was pointed out in IRC, thanks to eddyb!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307496 91177308-0d34-0410-b5e6-96231b3b80d8
Users of getHostCPUName should also use getHostCPUFeatures which will take care of making sure avx512 is disabled if the CPU doesn't support it. This is consistent with what we do for other CPUs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307495 91177308-0d34-0410-b5e6-96231b3b80d8
