When checking for tail call eligibility, we should use the correct CCAssignFn
for each argument, rather than just checking if the caller/callee is varargs or
not.
This is important for tail call lowering with varargs. If we don't check it,
then basically any varargs callee with parameters cannot be tail called on
Darwin, for one thing. If the parameters are all guaranteed to be in registers,
this should be entirely safe.
On top of that, not checking for this could potentially make it so that we have
the wrong stack offsets when checking for tail call eligibility.
Also refactor some of the stuff for CCAssignFnForCall and pull it out into a
helper function.
Update call-translator-tail-call.ll to show that we can now correctly tail call
on Darwin. Also add two extra tail call checks. The first verifies that we still
respect the caller's stack size, and the second verifies that we still don't
tail call when a varargs function has a memory argument.
Differential Revision: https://reviews.llvm.org/D67939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372897 91177308-0d34-0410-b5e6-96231b3b80d8
Modern processors predict the targets of an indirect branch regardless of
the size of any jump table used to glean its target address. Moreover,
branch predictors typically use resources limited by the number of actual
targets that occur at run time.
This patch changes the semantics of the option `-max-jump-table-size` to limit
the number of different targets instead of the number of entries in a jump
table. Thus, it is now renamed to `-max-jump-table-targets`.
Before, when `-max-jump-table-size` was specified, it could happen that
cluster jump tables could have targets used repeatedly, but each one was
counted and typically resulted in tables with the same number of entries.
With this patch, when specifying `-max-jump-table-targets`, tables may have
different lengths, since the number of unique targets is counted towards the
limit, but the number of unique targets in tables is the same, but for the
last one containing the balance of targets.
Differential revision: https://reviews.llvm.org/D60295
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372893 91177308-0d34-0410-b5e6-96231b3b80d8
During the review of D67434, it was recommended to make fmuladd's
behavior more explicit. D67434 depends on this interpretation.
Reviewers: efriedma, jfb, reames, scanon, lebedev.ri, spatel
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D67552
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372892 91177308-0d34-0410-b5e6-96231b3b80d8
We might be able to do better on the example in the test,
but in general, we should not scalarize a splatted vector
binop if there are other uses of the binop. Otherwise, we
can end up with code as we had - a scalar op that is
redundant with a vector op.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372886 91177308-0d34-0410-b5e6-96231b3b80d8
Currently m_Br only takes references to BasicBlock*, which limits its
flexibility. For example, you have to declare a variable, even if you
ignore the result or you have to have additional checks to make sure the
matched BB matches an expected one.
This patch adds m_BasicBlock and m_SpecificBB matchers, which can be
used like the existing matchers for constants or values.
I also had a look at the existing uses and updated a few. IMO it makes
the code a bit more explicit.
Reviewers: spatel, craig.topper, RKSimon, majnemer, lebedev.ri
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D68013
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372885 91177308-0d34-0410-b5e6-96231b3b80d8
Neither the base implementation of findCommutedOpIndices nor any in-tree target modifies the instruction passed in and there is no reason why they would in the future.
Committed on behalf of @hvdijk (Harald van Dijk)
Differential Revision: https://reviews.llvm.org/D66138
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372882 91177308-0d34-0410-b5e6-96231b3b80d8
The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917 <https://reviews.llvm.org/D61917>
As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086
The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535
But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.
The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.
Differential Revision: https://reviews.llvm.org/D67564
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372878 91177308-0d34-0410-b5e6-96231b3b80d8
TypeAttributeImpl inherits from EnumAttributeImpl which already defines anchor() as a virtual, so we should override this instead of redeclaring it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372877 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch fixes a bug that originated from passing a virtual exit block (nullptr) to `MachinePostDominatorTee::findNearestCommonDominator` and resulted in assertion failures inside its callee. It also applies a small cleanup to the class.
The patch introduces a new function in PDT that given a list of `MachineBasicBlock`s finds their NCD. The new overload of `findNearestCommonDominator` handles virtual root correctly.
Note that similar handling of virtual root nodes is not necessary in (forward) `DominatorTree`s, as right now they don't use virtual roots.
Reviewers: tstellar, tpr, nhaehnle, arsenm, NutshellySima, grosser, hliao
Reviewed By: hliao
Subscribers: hliao, kzhuravl, jvesely, wdng, yaxunl, dstuttard, t-tye, hiraditya, llvm-commits
Tags: #amdgpu, #llvm
Differential Revision: https://reviews.llvm.org/D67974
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372874 91177308-0d34-0410-b5e6-96231b3b80d8
Merge more Select pseudo instructions in emitSelect() by allowing other
instructions between them as long as they do not clobber CC.
Debug value instructions are now moved down to below the new PHIs instead of
erasing them.
Review: Ulrich Weigand
https://reviews.llvm.org/D67619
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372873 91177308-0d34-0410-b5e6-96231b3b80d8
I started this patch as a refactoring, tried to make a helper for
getting symbol names, similar to how we get section names
used in warning messages.
So this patch cleanups the code and fixes an issue: symbol names
in warning messages were not demangled.
Differential revision: https://reviews.llvm.org/D68012
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372867 91177308-0d34-0410-b5e6-96231b3b80d8
The changes here are based on the corresponding diffs for allowing FMF on 'select':
D61917
As discussed there, we want to have fast-math-flags be a property of an FP value
because the alternative (having them on things like fcmp) leads to logical
inconsistency such as:
https://bugs.llvm.org/show_bug.cgi?id=38086
The earlier patch for select made almost no practical difference because most
unoptimized conditional code begins life as a phi (based on what I see in clang).
Similarly, I don't expect this patch to do much on its own either because
SimplifyCFG promptly drops the flags when converting to select on a minimal
example like:
https://bugs.llvm.org/show_bug.cgi?id=39535
But once we have this plumbing in place, we should be able to wire up the FMF
propagation and start solving cases like that.
The change to RecurrenceDescriptor::AddReductionVar() is required to prevent a
regression in a LoopVectorize test. We are intersecting the FMF of any
FPMathOperator there, so if a phi is not properly annotated, new math
instructions may not be either. Once we fix the propagation in SimplifyCFG, it
may be safe to remove that hack.
Differential Revision: https://reviews.llvm.org/D67564
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372866 91177308-0d34-0410-b5e6-96231b3b80d8
The --bytes option uses the phrase "printable ASCII characters", but the
description section used simply "printable characters". To avoid any
confusion about locale impacts etc, this change adopts the former's
phrasing in both places. It also fixes a minor grammar issue in the
description.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D68016
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372865 91177308-0d34-0410-b5e6-96231b3b80d8
Main changes are mostly wording of some options, but this change also
fixes a switch reference so that a link is created and moves
--strip-sections into the ELF-specific area since it is only supported
for ELF currently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372864 91177308-0d34-0410-b5e6-96231b3b80d8
Summary of changes:
- Updated to reflect recent changes in assembler;
- Minor bugfixing and improvements.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372857 91177308-0d34-0410-b5e6-96231b3b80d8
Currently we can't use unique suffixes in section names to describe
stack sizes sections. E.g. '.stack_sizes [1]' will be treated as a regular section.
This happens because we recognize stack sizes section by name and
do not yet drop the suffix before the check.
The patch fixes it.
Differential revision: https://reviews.llvm.org/D68018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372853 91177308-0d34-0410-b5e6-96231b3b80d8
During legalisation we can end up with some pretty strange nodes, like shifts
of 0. We need to make sure we don't try to make long shifts of these, ending up
with invalid assembly instructions. A long shift with a zero immediate actually
encodes a shift by 32.
Differential Revision: https://reviews.llvm.org/D67664
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372839 91177308-0d34-0410-b5e6-96231b3b80d8
The crash might happen when we have either a broken or unsupported object
and trying to resolve relocations when dumping the .stack_sizes section.
For the test case I used a 32-bits ELF header and a 64-bit relocation.
In this case a null pointer is returned by the code instead of the relocation
resolver function and then we crash.
Differential revision: https://reviews.llvm.org/D67962
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372838 91177308-0d34-0410-b5e6-96231b3b80d8
This overload was left over from an operator new that was removed in
r123027. Fix it to match another operator new that was added in r248453.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372828 91177308-0d34-0410-b5e6-96231b3b80d8
I think we should be able to use shl instead of sshl and ushl for
positive constant shift values, unless I am missing something.
We already have the machinery in place to ensure we only replace
nodes, if the shift value is positive and <= the element width.
This is a generalization of an earlier patch rL372565.
Reviewers: t.p.northover, samparker, dmgreen, anemet
Reviewed By: anemet
Differential Revision: https://reviews.llvm.org/D67955
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372824 91177308-0d34-0410-b5e6-96231b3b80d8
-B is ignored for GNU objcopy compatibility after D67215/r371914.
* Delete mentions of -B from input-output-target.test - we have enough -B tests.
* Merge binary-input-with-arch.test into binary-output-target.test.
Reviewed By: rupprecht
Differential Revision: https://reviews.llvm.org/D67693
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372809 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of having different v128.load and v128.store instructions for
each MVT, just have one of each that is reused in all the
patterns. Also removes the HasSIMD128 predicate where accompanied by
HasUnimplementedSIMD128, since the latter implies the former.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67930
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372792 91177308-0d34-0410-b5e6-96231b3b80d8
Mimics the changes in r372209 to handle the change of quotes in
r372226. Probably isn't sufficient for windows, but unbreaks the cmake
flag at least.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372791 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, if an array element type size is 0, the number of
array elements will be set to 0, regardless of what user
specified. This implementation is done in the beginning where
BTF is mostly used to calculate the member offset.
For example,
struct s {};
struct s1 {
int b;
struct s a[2];
};
struct s1 s1;
The BTF will have struct "s1" member "a" with element count 0.
Now BTF types are used for compile-once and run-everywhere
relocations and we need more precise type representation
for type comparison. Andrii reported the issue as there
are differences between original structure and BTF-generated
structure.
This patch made the change to correctly assign "2"
as the number elements of member "a".
Some dead codes related to ElemSize compuation are also removed.
Differential Revision: https://reviews.llvm.org/D67979
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372785 91177308-0d34-0410-b5e6-96231b3b80d8
Second attempt: Now with ';' -> '|' replacement.
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
Differential Revision: https://reviews.llvm.org/D67195
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372784 91177308-0d34-0410-b5e6-96231b3b80d8
If we generate the gc.relocate, and then later prove two arguments to the statepoint are equivalent, we should canonicalize the gc.relocate to the form we would have produced if this had been known before rewriting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372771 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is again motivated by D67122 sanitizer check enhancement.
That patch seemingly worsens `-fsanitize=pointer-overflow`
overhead from 25% to 50%, which strongly implies missing folds.
For
```
#include <cassert>
char* test(char& base, signed long offset) {
__builtin_assume(offset < 0);
return &base + offset;
}
```
We produce
https://godbolt.org/z/r40U47
and again those two icmp's can be merged:
```
Name: 0
Pre: C != 0
%adjusted = add i8 %base, C
%not_null = icmp ne i8 %adjusted, 0
%no_underflow = icmp ult i8 %adjusted, %base
%r = and i1 %not_null, %no_underflow
=>
%neg_offset = sub i8 0, C
%r = icmp ugt i8 %base, %neg_offset
```
https://rise4fun.com/Alive/ALaphttps://rise4fun.com/Alive/slnN
There are 3 other variants of this pattern,
i believe they all will go into InstSimplify.
https://bugs.llvm.org/show_bug.cgi?id=43259
Reviewers: spatel, xbolva00, nikic
Reviewed By: spatel
Subscribers: efriedma, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67849
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372768 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is again motivated by D67122 sanitizer check enhancement.
That patch seemingly worsens `-fsanitize=pointer-overflow`
overhead from 25% to 50%, which strongly implies missing folds.
This pattern isn't exactly what we get there
(strict vs. non-strict predicate), but this pattern does not
require known-bits analysis, so it is best to handle it first.
```
Name: 0
%adjusted = add i8 %base, %offset
%not_null = icmp ne i8 %adjusted, 0
%no_underflow = icmp ule i8 %adjusted, %base
%r = and i1 %not_null, %no_underflow
=>
%neg_offset = sub i8 0, %offset
%r = icmp ugt i8 %base, %neg_offset
```
https://rise4fun.com/Alive/knp
There are 3 other variants of this pattern,
they all will go into InstSimplify:
https://rise4fun.com/Alive/bIDZhttps://bugs.llvm.org/show_bug.cgi?id=43259
Reviewers: spatel, xbolva00, nikic
Reviewed By: spatel
Subscribers: hiraditya, majnemer, vsk, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67846
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@372767 91177308-0d34-0410-b5e6-96231b3b80d8
