| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
This removes 500 transitive dependencies for a modification of
MCDwarf.h in a build of llc for a single out of line function
and reduces the build overhead by more than half without impacting
test time of check-llvm.
llvm-svn: 358255
|
| |
|
|
|
|
| |
includes from MCDwarf.h.
llvm-svn: 358254
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
are constant
There are 3 operands of maddld, (add (mul %1, %2), %3) and sometimes
they are constant. If there is constant operand, it takes extra li to
materialize the operand, and one more extra register too. So it's not
profitable to use maddld to optimize mul-add pattern.
Differential Revision: https://reviews.llvm.org/D60181
llvm-svn: 358253
|
| |
|
|
|
|
|
| |
Note, `DirIndex++` below is incorrect for DWARF 5, but it can be fixed
later after the file index is fixed.
llvm-svn: 358251
|
| |
|
|
|
|
| |
forwarding APIs look similar.
llvm-svn: 358250
|
| |
|
|
|
|
|
|
|
| |
This special section is named .symtab_shndx, according to gABI Chapter 4
Sections, and the name is used by some other tools. Though the section
type SHT_SYMTAB_SHNDX is what really matters, let's fix the typo
introduced in rL204769 :)
llvm-svn: 358247
|
| |
|
|
|
|
| |
This reapplies rL358161. That commit inadvertently reverted an exegesis file to an old version.
llvm-svn: 358246
|
| |
|
|
|
|
|
|
| |
local callsite.
NFC.
llvm-svn: 358244
|
| |
|
|
|
|
| |
No behavior change.
llvm-svn: 358241
|
| |
|
|
| |
llvm-svn: 358240
|
| |
|
|
|
|
| |
Found by inspection.
llvm-svn: 358239
|
| |
|
|
|
|
| |
Found by inspection.
llvm-svn: 358238
|
| |
|
|
|
|
|
|
| |
Found by oss-fuzz.
Also remove an else-after-return, this part has no behavior change.
llvm-svn: 358237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A lot of the code for printing special cases of operands in this
translation unit are static functions. While I too have suffered many
years of abuse at the hands of C, we should prefer private methods,
particularly when you start passing around *this as your first argument,
which is a code smell.
This will help make generic vs arch specific asm printing easier, as it
brings X86AsmPrinter more in line with other arch's derived AsmPrinters.
We will then be able to more easily move architecture generic code to
the base class, and architecture specific code to the derived classes.
Some other small refactorings while we're here:
- the parameter Op is now consistently OpNo
- add spaces around binary expressions. I know we're not millionaires
but c'mon.
Reviewers: echristo
Reviewed By: echristo
Subscribers: smeenai, hiraditya, llvm-commits, srhines, craig.topper
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60577
llvm-svn: 358236
|
| |
|
|
|
|
|
|
| |
member arg
Found by oss-fuzz.
llvm-svn: 358234
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The isLoopCarriedDep function does not correctly compute loop
carried dependences when the array index offset is negative
or the stride is smallar than the access size.
Patch by Denis Antrushin.
Differential Revision: https://reviews.llvm.org/D60135
llvm-svn: 358233
|
| |
|
|
|
|
|
|
|
|
| |
Same as the other ConstantRange overflow checking methods, but for
unsigned mul. In this case there is no cheap overflow criterion, so
using umul_ov for the implementation.
Differential Revision: https://reviews.llvm.org/D60574
llvm-svn: 358228
|
| |
|
|
|
|
|
|
|
|
|
| |
We currently assume profile hash conflicts will be caught by an upfront
check and we assert for the cases that escape the check. The assumption
is not always true as there are chances of conflict. This patch prints
a warning and skips annotating the function for the escaped cases,.
Differential Revision: https://reviews.llvm.org/D60154
llvm-svn: 358225
|
| |
|
|
|
|
|
| |
Some of these were legalizing into smaller vector types unnecessarily,
others were simply not supported yet.
llvm-svn: 358223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vectors of pointers.
Loads and store of values with type like <2 x p0> currently don't get imported
because SelectionDAG has no knowledge of pointer types. To leverage the existing
support for vector load/stores, we can bitcast the value to have s64 element
types instead. We do this as a custom legalization.
This patch also adds support for general loads of <2 x s64>, and relaxes some
type conditions on selecting G_BITCAST.
Differential Revision: https://reviews.llvm.org/D60534
llvm-svn: 358221
|
| |
|
|
|
|
|
|
|
|
| |
type legalization where the setcc result type is vXi1.
If the vector setcc has been legalized then we will need to convert a vector boolean of 0 or -1 to a scalar boolean of 0 or 1.
The added test case previously crashed in 32-bit mode by creating a setcc with an i64 condition that type legalization couldn't expand.
llvm-svn: 358218
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove atomic fadd pseudos use isel patterns instead.
This patch adds patterns for turning bitcasted atomic load/store into movss/sd.
It also removes the pseudo instructions for atomic RMW fadd. Instead just adding isel patterns for folding an atomic load into addss/sd. And relying on the new movss/sd store pattern to handle the write part.
This also makes the fadd patterns use VEX and EVEX instructions when AVX or AVX512F are enabled.
Differential Revision: https://reviews.llvm.org/D60394
llvm-svn: 358215
|
| |
|
|
|
|
|
|
|
|
|
|
| |
targets with X87, but no SSE2"
With correct test checks this time.
If we have X87, but not SSE2 we can atomicaly load an i64 value into the significand of an 80-bit extended precision x87 register using fild. We can then use a fist instruction to convert it back to an i64 integ
This matches what gcc and icc do for this case and removes an existing FIXME.
llvm-svn: 358214
|
| |
|
|
|
|
|
|
| |
targets with X87, but no SSE2"
I seem to have messed up the test checks.
llvm-svn: 358212
|
| |
|
|
|
|
|
|
|
|
|
|
| |
but no SSE2
If we have X87, but not SSE2 we can atomicaly load an i64 value into the significand of an 80-bit extended precision x87 register using fild. We can then use a fist instruction to convert it back to an i64 integer and store it to a stack temporary. From there we can do two 32-bit loads to get the value into integer registers without worrying about atomicness.
This matches what gcc and icc do for this case and removes an existing FIXME.
Differential Revision: https://reviews.llvm.org/D60156
llvm-svn: 358211
|
| |
|
|
|
|
|
|
|
| |
This reverts commit rL358161.
This patch have broken the test:
llvm/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s
llvm-svn: 358199
|
| |
|
|
|
|
|
|
| |
Use APInt instead of getZExtValue from the ConstantInt until we can confirm that the shift amount is in range.
Reduced from OSS-Fuzz #14169 - https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=14169
llvm-svn: 358192
|
| |
|
|
|
|
|
| |
There's a TODO comment about handling patterns with insert_subvector,
and we do want to match that.
llvm-svn: 358187
|
| |
|
|
|
|
| |
Completes SimplifyDemandedVectorElts's basic variable shuffle mask support which should help D60512 + D60562
llvm-svn: 358186
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RISCVMCCodeEmitter::expandAddTPRel asserts that the second operand must be
x4/tp. As we are not currently checking this in the RISCVAsmParser, the assert
is easy to trigger due to wrong assembly input.
This patch does a late check of this constraint.
An alternative could be using a singleton register class for x4/tp similar to
the current one for sp. Unfortunately it does not result in a good diagnostic.
Because add is an overloaded mnemonic, if no matching is possible, the
diagnostic of the first failing alternative seems to be used as the diagnostic
itself. This means that this case the %tprel_add is diagnosed as an invalid
operand (because the real add instruction only has 3 operands).
Differential Revision: https://reviews.llvm.org/D60528
llvm-svn: 358183
|
| |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D60437
Change-Id: I2183a6d825d0284b22705d423b88882992b236c5
llvm-svn: 358179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A bug/typo in Output::scalarString caused us to round-trip a StringRef
through a const char *. This meant that any strings with embedded nuls
were unintentionally cut short at the first such character. (It also
could have caused accidental buffer overruns, but it seems that all
StringRefs coming into this functions were formed from null-terminated
strings.)
This patch fixes the bug and adds an appropriate test.
Reviewers: sammccall, jhenderson
Subscribers: kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60505
llvm-svn: 358176
|
| |
|
|
| |
llvm-svn: 358174
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
// bo (build_vec ...undef, x, undef...), (build_vec ...undef, y, undef...) -->
// build_vec ...undef, (bo x, y), undef...
The lifetime of the nodes in these examples is different for variables versus constants,
but they are all build vectors briefly, so I'm proposing to catch them in this form to
handle all of the leading examples in the motivating test file.
Before we have build vectors, we might have insert_vector_element. After that, we might
have scalar_to_vector and constant pool loads.
It's going to take more work to ensure that FP vector operands are getting simplified
with undef elements, so this transform can apply more widely. In a non-loose FP environment,
we are likely simplifying FP elements to NaN values rather than undefs.
We also need to allow more opcodes down this path. Eg, we don't handle FP min/max flavors
yet.
Differential Revision: https://reviews.llvm.org/D60514
llvm-svn: 358172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add lowering pattern for llvm.aarch64.neon.vcvtfxs2fp.f16.i64
Reviewers: pbarrio, DavidSpickett, LukeGeeson
Reviewed By: LukeGeeson
Subscribers: javed.absar, kristof.beyls, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60259
llvm-svn: 358171
|
| |
|
|
| |
llvm-svn: 358170
|
| |
|
|
| |
llvm-svn: 358167
|
| |
|
|
|
|
| |
We need to add support for all variable shuffle mask ops, but VPPERM is the only one that already has test coverage.
llvm-svn: 358165
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a follow-up patch to D60504 to further improve
performance issues in computeKnownBitsFromAssume.
The patch is NFC, but may improve compile-time performance
if the compiler isn't clever enough to do the optimization
itself.
llvm-svn: 358163
|
| |
|
|
| |
llvm-svn: 358162
|
| |
|
|
| |
llvm-svn: 358161
|
| |
|
|
|
|
|
|
|
|
|
| |
Because of gp = sdata_start_address + 0x800, gp with signed twelve-bit offset
could covert most of the small data section. Linker relaxation could transfer
the multiple data accessing instructions to a gp base with signed twelve-bit
offset instruction.
Differential Revision: https://reviews.llvm.org/D57493
llvm-svn: 358150
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make DW_LNS_copy set the discriminator register to 0, to conform to
DWARF 4 & 5: "Then it sets the discriminator register to 0, and sets the
basic_block, prologue_end and epilogue_begin registers to false."
Because all of DW_LNE_end_sequence, DN_LNS_copy, and special opcodes reset
discriminator to 0, we can move discriminator=0 to appendRowToMatrix.
Also, make DW_LNS_copy print before appending the row, as it is similar
to a address+=0,line+=0 special opcode, which prints before appending
the row.
Reviewers: dblaikie, probinson, aprantl
Reviewed By: dblaikie
Subscribers: danielcdh, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60364
llvm-svn: 358148
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If the ObjectSizeOffsetEvaluator fails to fold the object size call, then it may
litter some unused instructions in the function. When done repeatably in
InstCombine, this results in an infinite loop. Fix this by tracking the set of
instructions that were inserted, then removing them on failure.
rdar://49172227
Differential revision: https://reviews.llvm.org/D60298
llvm-svn: 358146
|
| |
|
|
|
|
| |
The existing isel support already works for p0 once the legalizer accepts it.
llvm-svn: 358144
|
| |
|
|
| |
llvm-svn: 358143
|
| |
|
|
| |
llvm-svn: 358142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
i32 to i64 between the and & shl
foldMaskedShiftToScaledMask tries to reorder and & shl to enable the shl to fold into an LEA. But if there is an any_extend between them it doesn't work.
This patch modifies the code to look through any_extend from i32 to i64 when the and mask only uses bits that weren't from the extended part.
This will prevent a regression from D60358 caused by 64-bit SHL being narrowed to 32-bits when their upper bits aren't demanded.
Differential Revision: https://reviews.llvm.org/D60532
llvm-svn: 358139
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parser and disassembly parser to remove inconsistencies between VEX and EVEX.
Many of our instructions have both a _Int form used by intrinsics and a form
used by other IR constructs. In the EVEX space the _Int versions usually cover
all the capabilities include broadcasting and rounding. While the other version
only covers simple register/register or register/load forms. For this reason
in EVEX, the non intrinsic form is usually marked isCodeGenOnly=1.
In the VEX encoding space we were less consistent, but usually the _Int version
was the isCodeGenOnly version.
This commit makes the VEX instructions match the EVEX instructions. This was
done by manually studying the AsmMatcher table so its possible I missed some
cases, but we should be closer now.
I'm thinking about using the isCodeGenOnly bit to simplify the EVEX2VEX
tablegen code that disambiguates the _Int and non _Int versions. Currently it
checks register class sizes and Record the memory operands come from. I have
some other changes I was looking into for D59266 that may break the memory check.
I had to make a few scheduler hacks to keep the _Int versions from being treated
differently than the non _Int version.
Differential Revision: https://reviews.llvm.org/D60441
llvm-svn: 358138
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
be true with asserts. And move them earlier before we looked through operands that don't change size. NFC
These ifs were ensuring we don't have to handle types larger than 64 bits probably because we use getZExtValue in several places below them.
None of the callers of this code pass types larger than 64-bits so we can just assert instead of branching in release code.
I've also moved them earlier since we're just looking through operations that don't effect bit width.
This is prep work for some refactoring I plan to do to the (and (shl)) handling code.
llvm-svn: 358123
|