This reverts commit b05ecba6d687fcb3078509220c67458bf1d77a2e.
Apparently adding floor breaks AMDGPU somehow, so I have to back this out
while I look into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353065 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 8bbd570fd5205a04d88d2e5513a6e4adbd028039.
Apparently adding ffloor breaks AMDGPU somehow, so I need to back this out
while I look into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353064 91177308-0d34-0410-b5e6-96231b3b80d8
All of these instructions consume one encoded register and the other register is %st. They either write the result to %st or the encoded register. Previously we printed both arguments when the encoded register was written. And we printed one argument when the result was written to %st. For the stack popping forms the encoded register is always the destination and we didn't print both operands. This was inconsistent with gcc and objdump and just makes the output assembly code harder to read.
This patch changes things to always print both operands making us consistent with gcc and objdump. The parser should still be able to handle the single register forms just as it did before. This also matches the GNU assembler behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353061 91177308-0d34-0410-b5e6-96231b3b80d8
Add an intrinsic that takes 2 unsigned integers with the scale of them
provided as the third argument and performs fixed point multiplication on
them.
This is a part of implementing fixed point arithmetic in clang where some of
the more complex operations will be implemented as intrinsics.
Differential Revision: https://reviews.llvm.org/D55625
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353059 91177308-0d34-0410-b5e6-96231b3b80d8
This is no-functional-change-intended although there could
be intermediate variations caused by a difference in the
debug info produced by setting that from the builder's
insertion point.
I'm updating the IR test file associated with this code just
to show that the naming differences from using the builder
are visible.
The motivation for adding a helper function is that we are
likely to extend this code to deal with other overflow ops.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353056 91177308-0d34-0410-b5e6-96231b3b80d8
In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are required. Prior to this change,
this empty-named value appears in the command-line help text:
-some-option - some help text
=v1 - description 1
=v2 - description 2
= -
This change improves the help text for these sort of options in a number
of ways:
1) ValueOptional options with an empty-named value now print their help
text twice: both without and then with '=<value>' after the name. The
latter version then lists the allowed values after it.
2) Empty-named values with no help text in ValueOptional options are not
listed in the permitted values.
-some-option - some help text
-some-option=<value> - some help text
=v1 - description 1
=v2 - description 2
3) Otherwise empty-named options are printed as =<empty> rather than
simply '='.
4) Option values without help text do not have the '-' separator
printed.
-some-option=<value> - some help text
=v1 - description 1
=v2
=<empty> - description
It also tweaks the llvm-symbolizer -functions help text to not print a
trailing ':' as that looks bad combined with 1) above.
This is mostly a reland of r353048 which in turn was a reland of
r352750.
Reviewed by: ruiu, thopre, mstorsjo
Differential Revision: https://reviews.llvm.org/D57030
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353053 91177308-0d34-0410-b5e6-96231b3b80d8
In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are required. Prior to this change,
this empty-named value appears in the command-line help text:
-some-option - some help text
=v1 - description 1
=v2 - description 2
= -
This change improves the help text for these sort of options in a number
of ways:
1) ValueOptional options with an empty-named value now print their help
text twice: both without and then with '=<value>' after the name. The
latter version then lists the allowed values after it.
2) Empty-named values with no help text in ValueOptional options are not
listed in the permitted values.
-some-option - some help text
-some-option=<value> - some help text
=v1 - description 1
=v2 - description 2
3) Otherwise empty-named options are printed as =<empty> rather than
simply '='.
4) Option values without help text do not have the '-' separator
printed.
-some-option=<value> - some help text
=v1 - description 1
=v2
=<empty> - description
It also tweaks the llvm-symbolizer -functions help text to not print a
trailing ':' as that looks bad combined with 1) above.
This is mostly a reland of r352750.
Reviewed by: ruiu, thopre, mstorsjo
Differential Revision: https://reviews.llvm.org/D57030
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353048 91177308-0d34-0410-b5e6-96231b3b80d8
There was a missing space before the instruction name, and the newline
is redundant since MI::print by default adds one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353046 91177308-0d34-0410-b5e6-96231b3b80d8
Noticed while investigating PR40483, and fixes the basic test case from the bug - but not a more general case.
We're pretty weak at dealing with ADD/SUB combines compared to the SimplifyAssociativeOrCommutative/SimplifyUsingDistributiveLaws abilities that InstCombine can manage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353044 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes hidden codegen flag -print-schedule effectively reverting the
logic originally committed as r300311
(https://llvm.org/viewvc/llvm-project?view=revision&revision=300311).
Flag -print-schedule was originally introduced by r300311 to address PR32216
(https://bugs.llvm.org/show_bug.cgi?id=32216). That bug was about adding "Better
testing of schedule model instruction latencies/throughputs".
These days, we can use llvm-mca to test scheduling models. So there is no longer
a need for flag -print-schedule in LLVM. The main use case for PR32216 is
now addressed by llvm-mca.
Flag -print-schedule is mainly used for debugging purposes, and it is only
actually used by x86 specific tests. We already have extensive (latency and
throughput) tests under "test/tools/llvm-mca" for X86 processor models. That
means, most (if not all) existing -print-schedule tests for X86 are redundant.
When flag -print-schedule was first added to LLVM, several files had to be
modified; a few APIs gained new arguments (see for example method
MCAsmStreamer::EmitInstruction), and MCSubtargetInfo/TargetSubtargetInfo gained
a couple of getSchedInfoStr() methods.
Method getSchedInfoStr() had to originally work for both MCInst and
MachineInstr. The original implmentation of getSchedInfoStr() introduced a
subtle layering violation (reported as PR37160 and then fixed/worked-around by
r330615).
In retrospect, that new API could have been designed more optimally. We can
always query MCSchedModel to get the latency and throughput. More importantly,
the "sched-info" string should not have been generated by the subtarget.
Note, r317782 fixed an issue where "print-schedule" didn't work very well in the
presence of inline assembly. That commit is also reverted by this change.
Differential Revision: https://reviews.llvm.org/D57244
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353043 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents Constant Hoisting from pulling the constant out of the block,
allowing us to still produce LDRH/UXTH nodes. LDRB/UXTB (255) is already cheap
by the default getIntImmCost, but I've added it for clarity.
Differential Revision: https://reviews.llvm.org/D57671
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353040 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
... from 8.
`VALIGNDZ128rmbik XMM0 XMM0 K1 XMM3 RDI i_0x1 i_0x0 i_0x1` instruction already has 9 components.
It does not matter much in terms of performance, but avoiding allocation seems to come with low cost here..
Reviewers: courbet, gchatelet
Reviewed By: courbet
Subscribers: tschuett, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57654
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353022 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Up until the point i have looked in the source, i didn't even understood that
i can disable 'cluster' output. I have always silenced it via ` &> /dev/null`.
(And hoped it wasn't contributing much of the run time.)
While i expect that it has it's use-cases i never once needed it so far.
If i forget to silence it, console is completely flooded with that output.
How about not expecting users to opt-out of analyses,
but to explicitly specify the analyses that should be performed?
Reviewers: courbet, gchatelet
Reviewed By: courbet
Subscribers: tschuett, RKSimon, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57648
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353021 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, SCEV creates SCEVUnknown for every node of unreachable code. If we
have a huge amounts of such code, we will be littering SE with these nodes. We could
just state that they all are undef and save some memory.
Differential Revision: https://reviews.llvm.org/D57567
Reviewed By: sanjoy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353017 91177308-0d34-0410-b5e6-96231b3b80d8
We now print ST0 as 'st' when generating the clobber list for MS inline assembly in clang. This matches what the gcc reg name list expects.
Original commit message:
This fixes the test case in PR35982 by preventing MMX instructions that read MM0-7 from being moved below EMMS/FEMMS by the post RA scheduler.
Though as discussed in bugzilla, this is not a complete fix. There is still the possibility of reordering in IR or by the pre-RA scheduler.
Differential Revision: https://reviews.llvm.org/D57298
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353016 91177308-0d34-0410-b5e6-96231b3b80d8
This is a step back from the change I made in r352985. This appears to be more consistent with gcc and objdump behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353015 91177308-0d34-0410-b5e6-96231b3b80d8
Looking into gcc and objdump behavior more this was overly aggressive. If the register is encoded in the instruction we should print %st(0), if its implicit we should print %st.
I'll be making a more directed change in a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353013 91177308-0d34-0410-b5e6-96231b3b80d8
The MachO tests can run on any target, but require that the x86 backend
is available. Broaden the coverage of the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353012 91177308-0d34-0410-b5e6-96231b3b80d8
In llvm-nm, the symbol size was being computed only with --print-size option,
even though it was being printed in other cases, such as with --format=posix.
This patch simply removes the guard, so that the size is computed
independently of the later decision to print it or not.
Fixes PR39997.
Differential Revision: https://reviews.llvm.org/D57599
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353011 91177308-0d34-0410-b5e6-96231b3b80d8
There are 2 changes visible here:
1. There's no reason to limit this transform based on number
of condition registers. That diff allows PPC to produce
slightly better (dot-instructions should be generally good)
code.
Note: someone that cares about PPC codegen might want to
look closer at that output because it seems like we could
still improve this.
2. We (probably?) should not bother trying to form uaddo (or
other overflow ops) when there's no target support for such
an op. This goes beyond checking whether the op is expanded
because both PPC and AArch64 show better codegen for standard
types regardless of whether the op is legal/custom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@353001 91177308-0d34-0410-b5e6-96231b3b80d8
getTargetShuffleMask can only do this safely if we're extracting the lowest subvector from a vector of the same result type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352999 91177308-0d34-0410-b5e6-96231b3b80d8
This is the most important uaddo problem mentioned in PR31754:
https://bugs.llvm.org/show_bug.cgi?id=31754
...but that was overcome in x86 codegen with D57637.
That patch also corrects the inc vs. add regressions seen with the previous attempt at this.
Still, we want to make this matcher complete, so we can potentially canonicalize the pattern
even if it's an 'add 1' operation.
Pattern matching, however, shouldn't assume that we have canonicalized IR, so we match 4
commuted variants of uaddo.
There's also a test with a crazy type to show that the existing CGP transform based on this
matcher is not limited by target legality checks.
I'm not sure if the Hexagon diff means the test is no longer testing what it intended to
test, but that should be solvable in a follow-up.
Differential Revision: https://reviews.llvm.org/D57516
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352998 91177308-0d34-0410-b5e6-96231b3b80d8
Aim to use scalar source or lowest 128-bit vector directly.
We're still missing some VZMOVL_LOAD combines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@352994 91177308-0d34-0410-b5e6-96231b3b80d8
Jessica Paquette