| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
RuntimeDyldChecker.
llvm-svn: 214227
|
| |
|
|
| |
llvm-svn: 214225
|
| |
|
|
|
|
|
| |
This is more convenient for callers. No functionality change, this will
be used in a next patch to the gold plugin.
llvm-svn: 214218
|
| |
|
|
| |
llvm-svn: 214217
|
| |
|
|
| |
llvm-svn: 214216
|
| |
|
|
|
|
|
|
|
|
| |
full paths for its first argument.
This allows us to remove the annoying sed lines in the test cases, and write
direct references to file names in stub_addr calls (rather than <filename>
placeholders).
llvm-svn: 214211
|
| |
|
|
|
|
|
|
| |
This will let users in other libraries know which error occurred. In particular,
it will be possible to check if the parsing failed or if the file is not
bitcode.
llvm-svn: 214209
|
| |
|
|
|
|
| |
CoverageMappingContext::dump
llvm-svn: 214206
|
| |
|
|
| |
llvm-svn: 214205
|
| |
|
|
|
|
| |
relocation enum type. NFCI.
llvm-svn: 214204
|
| |
|
|
| |
llvm-svn: 214196
|
| |
|
|
|
|
| |
Also add missing comments about how the flags work.
llvm-svn: 214195
|
| |
|
|
|
|
| |
Set mayStore = 0 and enable named operand table.
llvm-svn: 214194
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Per feedback on r214111, we are going to use null to represent unspecified
parameter. If the type array is {null}, it means a function that returns void;
If the type array is {null, null}, it means a variadic function that returns
void. In summary if we have more than one element in the type array and the last
element is null, it is a variadic function.
rdar://17628609
llvm-svn: 214189
|
| |
|
|
|
|
|
| |
Per David Blaikie's review of r214135, this is a more natural way to
initialize.
llvm-svn: 214184
|
| |
|
|
| |
llvm-svn: 214181
|
| |
|
|
|
|
|
|
| |
convention if -mno-odd-spreg is used.
Differential Revision: http://reviews.llvm.org/D4682
llvm-svn: 214180
|
| |
|
|
|
|
|
|
|
| |
The test being performed is just an approximation anyway, so it really
shouldn't crash when things don't go entirely as expected.
Should fix PR20474.
llvm-svn: 214177
|
| |
|
|
|
|
|
| |
ARM does actually define the name for this conversion, so we should use it on
"-eabi" platforms.
llvm-svn: 214176
|
| |
|
|
|
|
|
|
| |
We need to make sure we use the softened version of all appropriate operands in
the libcall, or things go horribly wrong. This may entail actually executing a
1-stage softening.
llvm-svn: 214175
|
| |
|
|
| |
llvm-svn: 214159
|
| |
|
|
| |
llvm-svn: 214158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.
This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.
A few tests still fail, so I'll investigate those next.
This is part of PR5680.
llvm-svn: 214157
|
| |
|
|
| |
llvm-svn: 214155
|
| |
|
|
| |
llvm-svn: 214147
|
| |
|
|
| |
llvm-svn: 214146
|
| |
|
|
|
|
|
|
|
| |
The enum types array by design contains pointers to MDNodes rather than DIRefs.
Unique them when handling the enum types in DwarfDebug.
rdar://17628609
llvm-svn: 214139
|
| |
|
|
|
|
|
|
|
| |
Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.
Part of PR5680.
llvm-svn: 214135
|
| |
|
|
|
|
|
|
|
|
|
| |
DITypeArray is an array of DITypeRef, at its creation, we will create
DITypeRef (i.e use the identifier if the type node has an identifier).
This is the last patch to unique the type array of a subroutine type.
rdar://17628609
llvm-svn: 214132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Predict and serialize use-list order in bitcode. This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.
- Builds a full value-table up front in the writer, sets up a list of
use-list orders to write out, and discards the table. This is a
simpler first step than determining the order from the various
overlapping IDs of values on-the-fly.
- The shuffles stored in the use-list order list have an unnecessarily
large memory footprint.
- `blockaddress` expressions cause functions to be materialized
out-of-order. For now I've ignored this problem, so use-list orders
will be wrong for constants used by functions that have block
addresses taken. There are a couple of ways to fix this, but I
don't have a concrete plan yet.
- When materializing functions lazily, the use-lists for constants
will not be correct. This use case is out of scope: what should the
use-list order be, if it's incomplete?
This is part of PR5680.
llvm-svn: 214125
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Typedef DIArray to DITypedArray<DIDescriptor>. Also typedef DITypeArray as
DITypedArray<DITypeRef>.
This is the third of a series of patches to handle type uniqueing of the
type array for a subroutine type.
This commit should have no functionality change.
llvm-svn: 214115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the second of a series of patches to handle type uniqueing of the
type array for a subroutine type.
For vector and array types, getElements returns the array of subranges, so it
is a better name than getTypeArray. Even for class, struct and enum types,
getElements returns the members, which can be subprograms.
setArrays can set up to two arrays, the second is the templates.
This commit should have no functionality change.
llvm-svn: 214112
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first of a series of patches to handle type uniqueing of the
type array for a subroutine type.
This commit makes sure unspecified_parameter is a DIType to enable converting
the type array for a subroutine type to an array of DITypes.
This commit should have no functionality change. With this commit, we may
change unspecified type to be a DITrivialType instead of a DIType.
llvm-svn: 214111
|
| |
|
|
|
|
| |
All the others use bool, so these should too.
llvm-svn: 214106
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inspection in the proccess, and shuffle the logging in the DAG combiner
around a bit.
With this it is much easier to follow what the legalizer is doing. It
should even accurately present most of the strange legalization
operations where a single node is replaced by multiple nodes, etc. There
is still some information lost (we log SDNodes not SDValues so we don't
log which result is used for which thing), but I think this is much
closer to a usable system. Notably, this will make it *much* more
apparant when legalization is actually happening inside the combiner, or
when there is a cycle caused by interactions of the legalizer and the
combiner.
The "bug" I fixed here I'm not sure is remotely possible to trigger. We
were only adding one of the nodes in a replacement to the updated set
rather than all of the nodes in the replacement. Realistically, the
worst result of this are nodes not getting back onto the worklist in the
DAG combiner. I doubt it is possible to trigger this today, and
I certainly don't have any ideas about how, but this at least brings the
code into alignment with the principled operation of the routine.
llvm-svn: 214105
|
| |
|
|
|
|
|
| |
The default guess uses i32. This needs an address space argument
to really do the right thing in all cases.
llvm-svn: 214104
|
| |
|
|
| |
llvm-svn: 214101
|
| |
|
|
|
|
|
|
| |
Instructions: KAND{BWDQ}, KANDN{BWDQ}, KOR{BWDQ}, KXOR{BWDQ}, KXNOR{BWDQ}
Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com>
llvm-svn: 214081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While LLVM now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.
These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).
This patch implements the LLVM side of supporting this. As precedent
on other platforms suggests, ABI options are passed to the back-end as
features. Thus, this patch implements two features "elfv1" and "elfv2"
that select the desired ABI if present. (If not, the LLVM uses the
same default rules as now.)
llvm-svn: 214072
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The subtarget information is the ultimate source of truth for the feature set
that is enabled at this point. We would previously not propagate the feature
information to the subtarget. While this worked for the most part (features
would be enabled/disabled as requested), if another operation that changed the
feature bits was encountered (such as a mode switch via a .arm or .thumb
directive), we would end up resetting the behaviour of the architectural
extensions.
Handling this properly requires a slightly more complicated handling. We need
to check if the feature is now being toggled. If so, only then do we toggle the
features. In return, we no longer have to calculate the feature bits ourselves.
The test changes are mostly to the diagnosis, which is now more uniform (a nice
side effect!). Add an additional test to ensure that we handle this case
properly.
Thanks to Nico Weber for alerting me to this issue!
llvm-svn: 214057
|
| |
|
|
|
|
|
| |
Convert a loop to use range based iteration. Rename structure members to help
naming, and make structure definition anonymous. NFC.
llvm-svn: 214056
|
| |
|
|
|
|
|
|
|
|
| |
Rename to allowsMisalignedMemoryAccess.
On R600, 8 and 16 byte accesses are mostly OK with 4-byte alignment,
and don't need to be split into multiple accesses. Vector loads with
an alignment of the element type are not uncommon in OpenCL code.
llvm-svn: 214055
|
| |
|
|
|
|
|
|
|
|
|
| |
'J' represents a negative number suitable for an add/sub alias
instruction, but while preparing it to become an int64_t we were
mangling the sign extension. So "i32 -1" became 0xffffffffLL, for
example.
Should fix one half of PR20456.
llvm-svn: 214052
|
| |
|
|
|
|
| |
some -Werror bots, sorry for the noise.
llvm-svn: 214043
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions in the legalized DAG, and leverage it to combine long
sequences of instructions to PSHUFB.
Eventually, the other x86-instruction-specific shuffle combines will
probably all be driven out of this routine. But the real motivation is
to detect after we have fully legalized and optimized a shuffle to the
minimal number of x86 instructions whether it is profitable to replace
the chain with a fully generic PSHUFB instruction even though doing so
requires either a load from a constant pool or tying up a register with
the mask.
While the Intel manuals claim it should be used when it replaces 5 or
more instructions (!!!!) my experience is that it is actually very fast
on modern chips, and so I've gon with a much more aggressive model of
replacing any sequence of 3 or more instructions.
I've also taught it to do some basic canonicalization to special-purpose
instructions which have smaller encodings than their generic
counterparts.
There are still quite a few FIXMEs here, and I've not yet implemented
support for lowering blends with PSHUFB (where its power really shines
due to being able to zero out lanes), but this starts implementing real
PSHUFB support even when using the new, fancy shuffle lowering. =]
llvm-svn: 214042
|
| |
|
|
| |
llvm-svn: 214023
|
| |
|
|
|
|
|
|
| |
replacing nodes in the legalizer.
This caught a number of bugs for me during development.
llvm-svn: 214022
|
| |
|
|
|
|
| |
a missing transfer of debug information (without which tests fail).
llvm-svn: 214021
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
over each node in the worklist prior to combining.
This allows the combiner to produce new nodes which need to go back
through legalization. This is particularly useful when generating
operands to target specific nodes in a post-legalize DAG combine where
the operands are significantly easier to express as pre-legalized
operations. My immediate use case will be PSHUFB formation where we need
to build a constant shuffle mask with a build_vector node.
This also refactors the relevant functionality in the legalizer to
support this, and updates relevant tests. I've spoken to the R600 folks
and these changes look like improvements to them. The avx512 change
needs to be investigated, I suspect there is a disagreement between the
legalizer and the DAG combiner there, but it seems a minor issue so
leaving it to be re-evaluated after this patch.
Differential Revision: http://reviews.llvm.org/D4564
llvm-svn: 214020
|
| |
|
|
| |
llvm-svn: 214019
|