| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
registers to implement 128/256-bit operations without VLX.
llvm-svn: 321613
|
|
|
|
|
|
|
|
| |
false input being zero.
We can use zmm move with zero masking for this. We already had patterns for using a masked move, but we didn't check for the zero masking case separately.
llvm-svn: 321612
|
|
|
|
|
|
|
|
|
|
| |
vector to v8i1 pre-legalize.
The CONCAT_VECTORS will be lowered to INSERT_SUBVECTOR later. In the modified cases this seems to be enough to trick a later DAG combine into running in a different order than allows the ANDs to be removed.
I'll admit this is a bit of a hack that happens to work, but using CONCAT_VECTORS is more consistent with other legalization code anyway.
llvm-svn: 321611
|
|
|
|
|
|
| |
As it has a scalar source we don't treat it as a target shuffle so needs special handling.
llvm-svn: 321610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(Re-submission of D39937 with fixed tests.)
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, cfe-commits
Differential Revision: https://reviews.llvm.org/D41646
llvm-svn: 321609
|
|
|
|
| |
llvm-svn: 321608
|
|
|
|
|
|
| |
Don't combine buildvector(binop(),binop(),binop(),binop()) -> binop(buildvector(), buildvector()) if its a splat - keep the binop scalar and just splat the result to avoid large vector constants.
llvm-svn: 321607
|
|
|
|
|
|
|
| |
I wanted to commit this with r321603, but I failed to squash
the two commits.
llvm-svn: 321606
|
|
|
|
| |
llvm-svn: 321605
|
|
|
|
| |
llvm-svn: 321604
|
|
|
|
|
|
| |
PR35774.
llvm-svn: 321603
|
|
|
|
|
|
|
|
| |
legalization sees the i4 and changes to load/store.
Same for v2i1 and i2.
llvm-svn: 321602
|
|
|
|
|
|
|
|
| |
legalization sees the i4 and changes to load/store.
Same for i2 and v2i1.
llvm-svn: 321601
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocations only.
This is "Bug 35751 - .dynamic relocation entries omitted if output
contains only IFUNC relocations"
We have InX::RelaPlt and InX::RelaIPlt synthetic sections for PLT relocations.
They are usually live in rela.plt section. Problem appears when InX::RelaPlt
section is empty. In that case we did not produce normal set of dynamic tags
required, because logic was written in the way assuming we always have
non-IRelative relocations in rela.plt.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41592
llvm-svn: 321600
|
|
|
|
|
|
|
|
|
|
|
| |
Previously llvm-mc would silently accept code from testcase,
that contains invalid metadata symbol in section declaration.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D41641
llvm-svn: 321599
|
|
|
|
|
|
|
|
| |
don't have DQI.
We end up using an i8 load via an isel pattern from v8i1 anyway. This just makes it more explicit. This seems to improve codgen in some cases and I'd like to kill off some of the load patterns.
llvm-svn: 321598
|
|
|
|
|
|
| |
This is better handled by a DAG combine if its not already being done. No lit tests fail from the removal of these patterns.
llvm-svn: 321597
|
|
|
|
|
|
| |
I don't think anything would actually expect the other bits to be zero.
llvm-svn: 321596
|
|
|
|
| |
llvm-svn: 321595
|
|
|
|
|
|
| |
Use getMemBasePlusOffset and calculate proper pointer info and alignment for the second store.
llvm-svn: 321594
|
|
|
|
|
|
|
|
| |
member functions
A few tests need to be fixed
llvm-svn: 321593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adjust wording for const-qualification mismatch to be a little more clear.
Also add another diagnostic for a ref qualifier mismatch, which previously produced a useless error (this error path is simply very old; see rL119336):
Before:
error: cannot initialize object parameter of type 'X0' with an expression of type 'X0'
After:
error: 'this' argument to member function 'rvalue' is an lvalue, but function has rvalue ref-qualifier
Reviewers: rsmith, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39937
llvm-svn: 321592
|
|
|
|
|
|
| |
The test needs to be changed; it was exercising UB and that likely wasn't the intent of the test author. I simply removed the checks because I have absolutely no idea what this test was trying to accomplish. With multiple check patterns, no explanation, and no familiarity on my part with the ISA a true fix is going to have to come from someone familiar with the target.
llvm-svn: 321591
|
|
|
|
| |
llvm-svn: 321590
|
|
|
|
|
|
|
|
| |
The test in question was checking for a particular intepretation of undefined behavior. Relax the test to check that we simply don't crash.
Sorry for the breakage, I don't generally build AMDGPU locally and just saw the failure this morning.
llvm-svn: 321589
|
|
|
|
|
|
| |
Need to check targets in tests more carefully.
llvm-svn: 321588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang is inherently a cross compiler and can generate code for any target
enabled during build. It however requires to specify many parameters in the
invocation, which could be hardcoded during configuration process in the
case of single-target compiler. The purpose of configuration files is to
make specifying clang arguments easier.
A configuration file is a collection of driver options, which are inserted
into command line before other options specified in the clang invocation.
It groups related options together and allows specifying them in simpler,
more flexible and less error prone way than just listing the options
somewhere in build scripts. Configuration file may be thought as a "macro"
that names an option set and is expanded when the driver is called.
Use of configuration files is described in `UserManual.rst`.
Differential Revision: https://reviews.llvm.org/D24933
llvm-svn: 321587
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configuration file is read as a response file in which file names in
the nested constructs `@file` are resolved relative to the directory
where the including file resides. Lines in which the first non-whitespace
character is '#' are considered as comments and are skipped. Trailing
backslashes are used to concatenate lines in the same way as they
are used in shell scripts.
Differential Revision: https://reviews.llvm.org/D24926
llvm-svn: 321586
|
|
|
|
| |
llvm-svn: 321585
|
|
|
|
|
|
| |
Broadcast of sign/zero extended scalars resulting in unnecessary vector constants
llvm-svn: 321584
|
|
|
|
|
|
| |
To compare against (v2f32 build_vector(f32 uitofp(i32), f32 uitofp(i32)))
llvm-svn: 321583
|
|
|
|
|
|
| |
It caused buildbot fails.
llvm-svn: 321582
|
|
|
|
|
|
|
|
|
|
| |
This was raised in comments for D41592.
With current code we always assign parent
section for Rel[a] sections like
InX::RelaPlt or InX::RelaDyn, so checking
their parent for null is excessive.
llvm-svn: 321581
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Configuration file is read as a response file in which file names in
the nested constructs `@file` are resolved relative to the directory
where the including file resides. Lines in which the first non-whitespace
character is '#' are considered as comments and are skipped. Trailing
backslashes are used to concatenate lines in the same way as they
are used in shell scripts.
Differential Revision: https://reviews.llvm.org/D24926
llvm-svn: 321580
|
|
|
|
|
|
|
|
|
|
| |
If the callee and caller use different calling convensions, we cannot apply TCO if the callee requires arguments on stack; e.g. C calling convention and Fast CC use the same registers for parameter passing, but the stack offset is not necessarily same.
This patch also recommit r319218 "[PowerPC] Allow tail calls of fastcc functions from C CallingConv functions." by @sfertile since the problem reported in r320106 should be fixed.
Differential Revision: https://reviews.llvm.org/D40893
llvm-svn: 321579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If using a version script with a `local: *` in it, symbols in shared
libraries will still get default visibility if another shared library on
the link line has an undefined reference to the symbol. This is quite
surprising. Neither bfd nor gold have this behavior when linking a
shared library, and none of LLD's tests fail without this behavior, so
it seems safe to limit scanShlibUndefined to executables.
As far as executables are concerned, gold doesn't do any automatic
default visibility marking, and bfd issues a link error about a shared
library having a reference to a hidden symbol rather than silently
giving that symbol default visibility. I think bfd's behavior here is
preferable to LLD's, but that's something to be considered in a
follow-up.
Differential Revision: https://reviews.llvm.org/D41524
llvm-svn: 321578
|
|
|
|
|
|
|
|
| |
natively.
We should only be creating natively supported kshifts now.
llvm-svn: 321577
|
|
|
|
|
|
|
|
| |
This allows us to remove some isel patterns.
This is mostly NFC, but we now use KSHIFTB instead of KSHIFTW with DQI.
llvm-svn: 321576
|
|
|
|
|
|
|
|
|
|
| |
insertelement and extractelement
In one case, we were handling out of bounds, but not undef indices. In the other, we were handling undef (with the comment making the analogy to out of bounds), but not out of bounds. Be consistent and treat both undef and constant out of bounds indices as producing undefined results.
As a side effect, this also protects instcombine from having to handle large constant indices as we always simplify first.
llvm-svn: 321575
|
|
|
|
|
|
| |
UnqualifiedIdKind.
llvm-svn: 321574
|
|
|
|
|
|
|
|
| |
Went to reduce another fuzzer failure to find it's already been fixed, but the test case is slightly different so it's worth adding anyways.
Reduced from oss-fuzz #4768 test case
llvm-svn: 321573
|
|
|
|
| |
llvm-svn: 321572
|
|
|
|
|
|
|
|
|
|
|
| |
Fix code in LiveDebugVariables that was changing def MachineOperands to
uses, which will hit an assert for dead operands after the change to add
the renamable bit to MachineOperands. Avoid the assert by clearing the
dead bit before changing the operand to a use.
Fixes issue reported in out of tree target by Jesper Antonsson at Ericsson.
llvm-svn: 321571
|
|
|
|
| |
llvm-svn: 321570
|
|
|
|
| |
llvm-svn: 321569
|
|
|
|
| |
llvm-svn: 321568
|
|
|
|
| |
llvm-svn: 321567
|
|
|
|
| |
llvm-svn: 321566
|
|
|
|
|
|
|
|
| |
Initially, if the `c` constraint applied to the wrong data type that
causes LLVM to assert. This commit replaces the assert by an error
message.
llvm-svn: 321565
|
|
|
|
| |
llvm-svn: 321564
|