| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
operand into the Value interface just like the core print method is.
That gives a more conistent organization to the IR printing interfaces
-- they are all attached to the IR objects themselves. Also, update all
the users.
This removes the 'Writer.h' header which contained only a single function
declaration.
llvm-svn: 198836
|
| |
|
|
|
|
| |
It's unused in DwarfTypeUnit, as is expected.
llvm-svn: 198830
|
| |
|
|
| |
llvm-svn: 198819
|
| |
|
|
|
|
|
|
|
|
| |
In the stackmap format we advertise the constant field as signed.
However, we were determining whether to promote to a 64-bit constant
pool based on an unsigned comparison.
This fix allows -1 to be encoded as a small constant.
llvm-svn: 198816
|
| |
|
|
| |
llvm-svn: 198813
|
| |
|
|
|
|
|
|
|
| |
equivalents
This makes it easier to write a test that's mostly shared between
fission and non-fission (using FileCheck's multiple prefix support).
llvm-svn: 198806
|
| |
|
|
|
|
|
| |
having the include could cause weird layering problems between the IR
and MC libraries.
llvm-svn: 198796
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MIsNeedChainEdge, which is used by -enable-aa-sched-mi (AA in misched), had an
llvm_unreachable when -enable-aa-sched-mi is enabled and we reach an
instruction with multiple MMOs. Instead, return a conservative answer. This
allows testing -enable-aa-sched-mi on x86.
Also, this moves the check above the isUnsafeMemoryObject checks.
isUnsafeMemoryObject is currently correct only for instructions with one MMO
(as noted in the comment in isUnsafeMemoryObject):
// We purposefully do no check for hasOneMemOperand() here
// in hope to trigger an assert downstream in order to
// finish implementation.
The problem with this is that, had the candidate edge passed the
"!MIa->mayStore() && !MIb->mayStore()" check, the hoped-for assert would never
happen (which could, in theory, lead to incorrect behavior if one of these
secondary MMOs was volatile, for example).
llvm-svn: 198795
|
| |
|
|
| |
llvm-svn: 198794
|
| |
|
|
| |
llvm-svn: 198791
|
| |
|
|
|
|
| |
resolution works.
llvm-svn: 198780
|
| |
|
|
|
|
| |
It's not a real instruction any more and doesn't need encoding information.
llvm-svn: 198778
|
| |
|
|
|
|
|
|
| |
to the following two rules:
1) fold (vselect (build_vector AllOnes), A, B) -> A
2) fold (vselect (build_vector AllZeros), A, B) -> B
llvm-svn: 198777
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 198768
|
| |
|
|
| |
llvm-svn: 198763
|
| |
|
|
|
|
|
| |
Mark them as requiring 16-bit mode for now, since we don't yet have
relaxation support for FK_Data_2.
llvm-svn: 198762
|
| |
|
|
|
|
|
|
| |
They do *different* things to %esp, so they are not equivalent.
Rename PUSHi8 to PUSH32i8 and add the missing PUSH16i8.
llvm-svn: 198761
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We can't do a perfect job here. We *have* to allow (%dx) even in 64-bit
mode, for example, because it might be used for an unofficial form of
the in/out instructions. We actually want to do a better job of validation
*later*. Perhaps *instead* of doing it where we are at the moment.
But for now, doing what validation we *can* do in the place that the code
already has its validation, is an improvement.
llvm-svn: 198760
|
| |
|
|
|
|
|
|
|
|
| |
It seems there is no separate instruction class for having AdSize *and*
OpSize bits set, which is required in order to disambiguate between all
these instructions. So add that to the disassembler.
Hm, perhaps we do need an AdSize16 bit after all?
llvm-svn: 198759
|
| |
|
|
|
|
|
|
|
| |
Where "where possible" means that it's an immediate value and it's below
0x10000. In fact GAS will either truncate or error with larger values,
and will insist on using the addr32 prefix to get 32-bit addressing. So
perhaps we should do that, in a later patch.
llvm-svn: 198758
|
| |
|
|
|
|
|
| |
JCXZ should have the 0x67 prefix only if we're in 32-bit mode, so make that
appropriately conditional. And JECXZ needs the prefix instead.
llvm-svn: 198757
|
| |
|
|
|
|
|
|
|
|
| |
I couldn't see how to do this sanely without splitting RETQ from RETL.
Eric says: "sad about the inability to roundtrip them now, but...".
I have no idea what that means, but perhaps it wants preserving in the
commit comment.
llvm-svn: 198756
|
| |
|
|
| |
llvm-svn: 198755
|
| |
|
|
| |
llvm-svn: 198754
|
| |
|
|
| |
llvm-svn: 198753
|
| |
|
|
|
|
|
|
|
| |
This fixes the bulk of 16-bit output, and the corresponding test case
x86-16.s now looks mostly like the x86-32.s test case that it was
originally based on. A few irrelevant instructions have been dropped,
and there are still some corner cases to be fixed in subsequent patches.
llvm-svn: 198752
|
| |
|
|
| |
llvm-svn: 198745
|
| |
|
|
|
|
|
|
|
|
|
|
| |
support abs-differences.
Modern versions of OSX/Darwin's ld (ld64 > 97.17) have an optimisation present that allows the back end to omit relocations (and replace them with an absolute difference) for FDE some text section refs.
This patch allows a backend to opt-in to this behaviour by setting "DwarfFDESymbolsUseAbsDiff". At present, this is only enabled for modern x86 OSX ports.
test changes by David Fang.
llvm-svn: 198744
|
| |
|
|
|
|
|
| |
when lower build_vector if result value type mismatch with operand
value type.
llvm-svn: 198743
|
| |
|
|
|
|
| |
encode them correctly.
llvm-svn: 198740
|
| |
|
|
| |
llvm-svn: 198739
|
| |
|
|
| |
llvm-svn: 198738
|
| |
|
|
|
|
|
|
|
| |
I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
llvm-svn: 198737
|
| |
|
|
|
|
|
| |
Operands which involved label arithemetic would previously fail to parse. This
corrects that by adding the additional case for the shift operand validation.
llvm-svn: 198735
|
| |
|
|
|
|
| |
insert element in instruction combine.
llvm-svn: 198730
|
| |
|
|
| |
llvm-svn: 198720
|
| |
|
|
|
|
| |
This makes it available to tools that don't link with target (like llvm-ar).
llvm-svn: 198708
|
| |
|
|
|
|
|
|
|
|
|
|
| |
take type from the new symbol but merge them so that the type
is never "downgraded".
This is probably quite rare, except for IFUNC symbols which
we used to misassemble, losing the IFUNC type.
Fixes #18372.
llvm-svn: 198706
|
| |
|
|
| |
llvm-svn: 198702
|
| |
|
|
|
|
|
| |
With the gnu objc runtime private strings are used. Since we only need to
produce a unique label, the fix is to just drop the asserts.
llvm-svn: 198701
|
| |
|
|
| |
llvm-svn: 198700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds the pre-UAL aliases of fconsts and fconstd for
vmov.f32 and vmov.f64. They use an InstAlias rather than a
MnemonicAlias to properly support the predicate operand.
We need to support encoded 8-bit constants in order to implement the
pre-UAL fconsts/fconstd aliases for vmov.f32/vmov.f64, so this
commit also fixes parsing of encoded floating point constants used
in vmov.f32/vmov.f64 instructions. Now we can support assembly code
like this:
fconsts s0, #0x70
which is equivalent to vmov.f32 s0, #1.0.
Most of the code was already in place to support this feature.
Previously the code was trying to accept encoded 8-bit float
constants for the vmov.f32/vmov.f64 instructions. It looks like the
support for parsing encoded floats was lost in a refactoring in
commit r148556 and we did not have any tests in place to catch it.
The change in this commit is to keep the parsed value as a 32-bit
float instead of a 64-bit double because that is what the isFPImm()
function expects to find. There is no loss of precision by using a
32-bit float here because we are still limited to an 8-bit encoded
value in the end.
Additionally, we explicitly reject encoded 8-bit floats for
vmovf.32/64. This is the same as the current behavior, but we now do
it explicitly rather than accidently.
llvm-svn: 198697
|
| |
|
|
| |
llvm-svn: 198696
|
| |
|
|
|
|
| |
be quite accurate. =]
llvm-svn: 198690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are part of the core IR library in order to support dumping and other
basic functionality.
Rename the 'Assembly' include directory to 'AsmParser' to match the
library name and the only functionality left their -- printing has been
in the core IR library for quite some time.
Update all of the #includes to match.
All of this started because I wanted to have the layering in good shape
before I started adding support for printing LLVM IR using the new pass
infrastructure, and commandline support for the new pass infrastructure.
llvm-svn: 198688
|
| |
|
|
|
|
|
|
|
|
| |
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
llvm-svn: 198685
|
| |
|
|
|
|
| |
There is no test cases for D tuple as the original test cases are too large. As the spill/fill of the D tuple is similar to the Q tuple, the correctness can be guaranteed.
llvm-svn: 198684
|
| |
|
|
|
|
| |
tuples such as QPair/QTriple/QQuad. There is no test case for D tuple as the original test cases are too large. As the copy of the D tuple is similar to the Q tuple, the correctness can be guaranteed.
llvm-svn: 198682
|
| |
|
|
|
|
| |
Also, correct the offsets for FixupsKindInfo.
llvm-svn: 198681
|
| |
|
|
|
|
| |
InlineSpiller::foldMemoryOperand needs to handle undef call operands.
llvm-svn: 198679
|