Rename to lowerRETURNADDR, lowerFRAMEADDR in order to be consistent with the
LLVM coding style and the other functions in this file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343752 91177308-0d34-0410-b5e6-96231b3b80d8
A `defined(NDEBUG) && !defined(LLVM_ENABLE_DUMP)` build does not call
writeEscaped and there will be no `SBWriteZeroLatency` in the output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343751 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
GNU nm (and other nm implementations, such as "go tool nm") prints an explicit "no symbols" message when an object file has no symbols. Currently llvm-nm just doesn't print anything. Adding an explicit "no symbols" message will allow llvm-nm to be used in place of nm: some scripts and build processes use `nm <file> | grep "no symbols"` as a test to see if a file has no symbols. It will also be more familiar to anyone used to nm.
That said, the format implemented here is slightly different, in that it doesn't print the tool name in the message (which IMHO is not useful to include).
Demo:
```
$ for nm in nm bin/llvm-nm ; do echo "nm implementation: $nm"; $nm /tmp/foo{1,2}.o; echo; done
nm implementation: nm
/tmp/foo1.o:
nm: /tmp/foo1.o: no symbols
/tmp/foo2.o:
0000000000000000 T foo2
nm implementation: bin/llvm-nm
/tmp/foo1.o:
no symbols
/tmp/foo2.o:
0000000000000000 T foo2
```
Reviewers: MaskRay
Reviewed By: MaskRay
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D52810
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343742 91177308-0d34-0410-b5e6-96231b3b80d8
r343712 performed this optimisation during instruction selection. As Eli
Friedman pointed out in post-commit review, implementing this as a DAGCombine
might allow opportunities for further optimisations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343741 91177308-0d34-0410-b5e6-96231b3b80d8
There was some duplicated logic for using the LocInfo of a CCValAssign in
order to convert from the ValVT to LocVT or vice versa. Resolve this by
factoring out convertLocVTFromValVT from unpackFromRegLoc. Also rename
packIntoRegLoc to the more appropriate convertValVTToLocVT and call these
helper functions consistently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343737 91177308-0d34-0410-b5e6-96231b3b80d8
MCContext does not destroy MCSymbols on shutdown. So, rather than putting
SmallVectors (which may heap-allocate) inside MCSymbolWasm, use unowned pointer
to a WasmSignature instead. The signatures are now owned by the AsmPrinter.
Also uses WasmSignature instead of param and result vectors in TargetStreamer,
and leaves some TODOs for further simplification.
Differential Revision: https://reviews.llvm.org/D52580
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343733 91177308-0d34-0410-b5e6-96231b3b80d8
If present, PHI nodes must appear before non-PHI nodes in a basic block. The
register allocator relies on this and will fail to eliminate PHI's that do not
meet this requirement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343731 91177308-0d34-0410-b5e6-96231b3b80d8
We're a long way from D50992 and D51553, but this is where we have to start.
We weren't back-propagating undefs into binop constant values for anything but
add/sub/mul/and/or/xor.
This is likely because we have to be careful about not introducing UB/poison
with div/rem/shift. But I suspect we already are getting the poison part wrong
for add/sub/mul (although it may not be possible to expose the bug currently
because we use SimplifyDemandedVectorElts from a limited set of opcodes).
See the discussion/implementation from D48987 and D49047.
This patch just enables functionality for FP ops because those do not have
UB/poison potential.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343727 91177308-0d34-0410-b5e6-96231b3b80d8
The additional patterns needed for this aren't overwhelming and introducing extra bitcasts during lowering limits our ability to do computeNumSignBits. Not that I have a good example of that for select. I'm just becoming increasingly grumpy about promotion of AND/OR/XOR. SELECT was just a lot easier to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343723 91177308-0d34-0410-b5e6-96231b3b80d8
Although we can't write a tablegen pattern to remove redundant
splitf64+buildf64 pairs due to the multiple return values, we can handle it
with some C++ selection code. This is simpler than removing them after
instruction selection through RISCVDAGToDAGISel::PostprocessISelDAG, as was
done previously.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343712 91177308-0d34-0410-b5e6-96231b3b80d8
The register class is all that's important for the pseudo instructions. We can use patterns to handle the different types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343709 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a 'WriteCopy' [WriteLoad, WriteStore] schedule sequence instead to better model the behaviour
Found by @andreadb during llvm-mca testing on btver2 which was crashing on "zero uop" WriteRMW only instructions
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343708 91177308-0d34-0410-b5e6-96231b3b80d8
-verify-machineinstrs was implemented as a simple bool. As a result, the
'VerifyMachineCode == cl::BOU_UNSET' used by EXPENSIVE_CHECKS to make it on by
default but possible to disable didn't work as intended. Changed
-verify-machineinstrs to a boolOrDefault to correct this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343696 91177308-0d34-0410-b5e6-96231b3b80d8
1. Fix include ordering.
2. Improve variable name (width is bitwidth not number-of-elements).
3. Add local Opcode variable to reduce code duplication.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343694 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a problem where the register allocator fails to eliminate a PHI
because there's a non-PHI in the middle of the PHI instructions at the start
of a BB.
This G_TRUNC can be better placed but this at least fixes the correctness issue
quickly. I'll follow up with a patch to the verifier to catch this kind of bug
in future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343693 91177308-0d34-0410-b5e6-96231b3b80d8
This function will deal with more than shuffles with D50992, and I
have another potential per-element fold that could live here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343692 91177308-0d34-0410-b5e6-96231b3b80d8
This patch teaches class RegisterFile how to analyze register writes from
instructions that are move elimination candidates.
In particular, it teaches it how to check if a move can be effectively eliminated
by the underlying PRF, and (if necessary) how to perform move elimination.
The long term goal is to allow processor models to describe instructions that
are valid move elimination candidates.
The idea is to let register file definitions in tablegen declare if/when moves
can be eliminated.
This patch is a non functional change.
The logic that performs move elimination is currently disabled. A future patch
will add support for move elimination in the processor models, and enable this
new code path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343691 91177308-0d34-0410-b5e6-96231b3b80d8
deserializeMCOperand - ensure that we at least match the first character of the sscanf pattern before calling
This reduces llvm-exegesis uops analysis of the instructions supported from btver2 from 5m13s to 2m1s on debug builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343690 91177308-0d34-0410-b5e6-96231b3b80d8
Fix use of SSE1 registers for f32 ops in no-x87 mode.
Notably, allow use of SSE instructions for f32 operations in 64-bit
mode (but not 32-bit which is disallowed by callign convention).
Also avoid translating memset/memcopy/memmove into SSE registers
without X87 for 32-bit mode.
This fixes PR38738.
Reviewers: nickdesaulniers, craig.topper
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D52555
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343689 91177308-0d34-0410-b5e6-96231b3b80d8
Two cases in a ThinLTO test were passing for the wrong reasons, since
rL340374. The tests were supposed to be testing that files were being
pruned due to the cache size, but they were in fact being pruned because
they were older than the default expiration period of 1 week.
This change fixes the tests by explicitly setting the expiration time to
the maximum value. This required the option to be exposed in llvm-lto.
By assigning all files in the cache a similar time, it is possible to see
that the newest files are still being kept, and that we aren't passing
for the wrong reason again. In the event that the entry expiration were
to expire for them, then the test would start failing, because these
files would be removed too.
Reviewed by: rnk, inglorion
Differential Revision: https://reviews.llvm.org/D51992
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343687 91177308-0d34-0410-b5e6-96231b3b80d8
This patch makes sure that a register is only hinted once to RA. In extreme
cases the same register can otherwise be hinted numerous times and cause a
compile time slowdown.
Review: Simon Pilgrim
https://reviews.llvm.org/D52826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343686 91177308-0d34-0410-b5e6-96231b3b80d8
The patterns as defined are correct only when XLen==32.
This is another preparatory patch for a set of patches that flesh out RV64
codegen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343679 91177308-0d34-0410-b5e6-96231b3b80d8
1. brcond operates on an condition.
2. atomic_fence and the pseudo AMO instructions should all take xlen immediates
This allows the same definitions and patterns to work for RV64 (XLenVT==i64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343678 91177308-0d34-0410-b5e6-96231b3b80d8
The generated code is incorrect anyway, and this test adds noise to the
upcoming set of patches that flesh out RV64 support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343675 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The new buffer/tbuffer intrinsics handle an out-of-range immediate
offset by moving/adding offset&-4096 to a vgpr, leaving an in-range
immediate offset, with a chance of the move/add being CSEd for similar
loads/stores.
However it turns out that a negative offset in a vgpr is illegal, even
if adding the immediate offset makes it legal again.
Therefore, this commit disables the offset&-4096 thing if the offset is
negative.
Differential Revision: https://reviews.llvm.org/D52683
Change-Id: Ie02f0a74f240a138dc2a29d17cfbd9e350e4ed13
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343672 91177308-0d34-0410-b5e6-96231b3b80d8
Remove uop on WriteRMW and move it into the few instructions that need it.
Match AMD Fam16h SOG + llvm-exegesis tests
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343671 91177308-0d34-0410-b5e6-96231b3b80d8
I was expecting this to be a nfc but Silvermont seems to be setup a little differently:
// A folded store needs a cycle on MEC_RSV for the store data, but it does not need an extra port cycle to recompute the address.
def : WriteRes<WriteRMW, [SLM_MEC_RSV]>;
So moving from WriteStore to WriteRMW reduces predicted port pressure, confirmed by @craig.topper that this is correct.
Differential Revision: https://reviews.llvm.org/D52740
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@343670 91177308-0d34-0410-b5e6-96231b3b80d8
