| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
There's no point in finding a function to use for remark output when we're
not going to emit anything.
llvm-svn: 341252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of counting the size of the entire module every time we run a pass,
pass along a delta instead and use that to emit the remark.
This means we only have to use (on average) smaller IR units to calculate
instruction counts. E.g, in a BB pass, we only need to look at the delta of
the BB instead of the delta of the entire module.
6/6
(This improved compile time for size remarks on sqlite3 + O2 significantly)
llvm-svn: 341250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same vein as the previous commits. Pre-calculate the size of
the module and use that to decide if we're going to emit a
remark.
This one comes with a FIXME and TODO. First off, CallGraphSCC
and CallGraphNode don't have a getInstructionCount function. So,
for now, we do the same thing as in a module pass.
Second off, we're not really saving anything here yet, because
as before, I need to change emitInstrCountChangedRemark to take
in a delta. Keeping the patches small though, so that's coming up
next.
5/6
llvm-svn: 341249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same as the previous NFC commits in the same vein.
This one introduces a TODO. I'm going to change emitInstrCountChangedRemark
so that it takes in a delta. Since the delta isn't necessary yet, it's not
there. For now, this means that we're calculating the size of the module
twice.
Just done separately to keep the patches small.
4/6
llvm-svn: 341248
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Another commit reducing compile time in size remarks.
Cache the size of the module and loop, and update values based
off of deltas instead. Avoid recalculating the size of the
whole module whenever possible.
3/6
llvm-svn: 341247
|
| |
|
|
|
|
|
|
|
|
|
| |
Size remarks are slow due to lots of recalculation of the module.
This is similar to the previous commit. Cache the size of the module and
update counts in basic block passes based off a less-expensive delta.
2/6
llvm-svn: 341246
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Size remarks are slow due to lots of recalculation of the module.
Pre-calculate the module size and initial function size for a remark. Use
deltas calculated using the less-expensive function IR count to update the
module counts for Function passes.
1/6
llvm-svn: 341245
|
| |
|
|
|
|
|
|
| |
Since we changed the storage for the PID in PIDRecord instances, we need
to also update the way we load the data from a DataExtractor through the
RecordInitializer.
llvm-svn: 341243
|
| |
|
|
|
|
|
|
|
| |
Previously we've been reading and writing the wrong types which only
worked in little endian implementations. This time we're writing the
same typed values the runtime is using, and reading them appropriately
as well.
llvm-svn: 341241
|
| |
|
|
|
|
|
| |
Previously we were reading only a uint16_t when we really needed to read
an int32_t from the log.
llvm-svn: 341239
|
| |
|
|
|
|
|
|
| |
Support required to build the Hexagon Linux kernel.
Differential Revision: https://reviews.llvm.org/D51363
llvm-svn: 341238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows us to let the compiler do the right thing for when
handling big-endian and little-endian records for FDR mode function
records.
Previously, we assumed that the encoding was little-endian that reading
the first byte to look for the function id and function record types was
ordered in a little-endian manner. This change allows us to better
handle function records where the first four bytes may actually be
encoded in big-endian thus giving us the wrong bytes where we're seeking
the function information from.
This is a follow-up to D51210 and D51289.
llvm-svn: 341236
|
| |
|
|
|
|
|
|
|
|
|
| |
This change makes the writer implementation more consistent with the way
fields are written down to avoid assumptions on bitfield order and
padding. We also fix an inconsistency between the type returned by the
`delta()` accessor to match the data member it's returning.
This is a follow-up to D51289 and D51210.
llvm-svn: 341230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following D50807, and heading towards D50664, this intermediary change does the following:
1. Upgrade all custom Error types in llvm/trunk/lib/DebugInfo/ to use the new StringError behavior (D50807).
2. Implement std::is_error_code_enum and make_error_code() for DebugInfo error enumerations.
3. Rename GenericError -> PDBError (the file will be renamed in a subsequent commit)
4. Update custom error messages to follow the same formatting: (\w\s*)+\.
5. Keep generic "file not found" (ENOENT) errors as they are in PDB code. Previously, there used to be a custom enumeration for that purpose.
6. Remove a few extraneous LF in log() implementations. Printing LF is a responsability at a higher level, not at the error level.
Differential Revision: https://reviews.llvm.org/D51499
llvm-svn: 341228
|
| |
|
|
|
|
|
|
|
|
| |
This patch recognizes shuffles that shift elements and fill with zeros. I've copied and modified the shift matching code we use for normal vector registers to do this. I'm not sure if there's a good way to share more of this code without making the existing function more complex than it already is.
This will be used to enable kshift intrinsics in clang.
Differential Revision: https://reviews.llvm.org/D51401
llvm-svn: 341227
|
| |
|
|
|
|
|
|
|
|
|
| |
This change makes the XRay Trace loading functions first use a
little-endian data extractor, then on failures try a big-endian data
extractor. Without this change, the trace loading facility will not work
with data written from a big-endian machine.
Follow-up to D51210 and D51289.
llvm-svn: 341226
|
| |
|
|
|
|
|
|
|
| |
Before this patch, the FDRTraceWriter would not take endianness into
account when writing data into the output stream.
This is a follow-up to D51289 and D51210.
llvm-svn: 341223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions.
The presence of a ReadAdvance for input operand #0 is problematic
because it changes the input latency of the register used as the base address
for the folded load.
A broadcast cannot start executing if the load address hasn't been computed yet.
In the llvm-mca example, the VBROADCASTSS is dependent on the address generated
by the LEAQ. That means, it cannot start until LEAQ reaches the write-back
stage. If we apply ReadAdvance, then we wrongly assume that the load can start 3
cycles in advance.
Differential Revision: https://reviews.llvm.org/D51534
llvm-svn: 341222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `mtc1` and `mfc1` definitions in the MipsInstrFPU.td have MMRel,
but do not have StdMMR6Rel tags. When these instructions are emitted
for microMIPS R6 targets, `Mips::MipsR62MicroMipsR6` nor
`Mips::Std2MicroMipsR6` cannot find correct op-codes and as a result the
backend uses mips32 variant of the instructions encoding.
The patch fixes this problem by adding the StdMMR6Rel tag and check
instructions encoding in the test case.
Differential revision: https://reviews.llvm.org/D51482
llvm-svn: 341221
|
| |
|
|
|
|
|
|
|
|
|
| |
The intention is to enable the extract_vector_elt load combine,
and doing this for other operations interferes with more
useful optimizations on vectors.
Handle any type of load since in principle we should do the
same combine for the various load intrinsics.
llvm-svn: 341219
|
| |
|
|
|
|
|
| |
Adds the same checks we already do for ints to floats.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8698
llvm-svn: 341216
|
| |
|
|
| |
llvm-svn: 341215
|
| |
|
|
|
|
|
|
|
|
| |
This simplifies the implementation of the metadata lookup by using
scoped enums, rather than using enum classes. This way we can get the
number-name mapping without having to resort to comments.
Follow-up to D51289.
llvm-svn: 341205
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49855
llvm-svn: 341202
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49183
llvm-svn: 341200
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49180
llvm-svn: 341199
|
| |
|
|
| |
llvm-svn: 341198
|
| |
|
|
|
|
|
|
| |
Original version of the code relied on implementation-defined order of bitfields.
Follow-up on D51210.
llvm-svn: 341194
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49172
llvm-svn: 341193
|
| |
|
|
| |
llvm-svn: 341191
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the number of micro opcodes, and processor resource cycles for
the following AVX instructions:
vinsertf128rr/rm
vperm2f128rr/rm
vbroadcastf128
Tests have been regenerated using the usual scripts in the llvm/utils directory.
Differential Revision: https://reviews.llvm.org/D51492
llvm-svn: 341185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch defines two new base types called `RecordProducer` and
`RecordConsumer` which have default implementations for convenience
(particularly for testing).
A `RecordProducer` implementation has one member function called
`produce()` which serves as a factory constructor for `Record`
instances. This code exercises the `RecordInitializer` code path in the
implementation for `FileBasedRecordProducer`.
A `RecordConsumer` has a single member function called `consume(...)`
which, as the name implies, consumes instances of
`std::unique_ptr<Record>`. We have two implementations, one of which is
used in the test to generate a vector of `std::unique_ptr<Record>`
similar to how the `LogBuilder` implementation works.
We introduce a test in `FDRProducerConsumerTest` which ensures that
records we write through the `FDRTraceWriter` can be loaded by the
`FileBasedRecordProducer`. The record(s) loaded this way are written
again through the `FDRTraceWriter` into a separate string, which we then
compare. This ensures that the read-in bytes to create the `Record`
instances in memory can be replicated when written out through the
`FDRTraceWriter`.
This change depends on D51210 and is part of the refactoring of D50441
into smaller, more focused changes.
Reviewers: eizan, kpw
Subscribers: mgorny, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D51289
llvm-svn: 341180
|
| |
|
|
| |
llvm-svn: 341178
|
| |
|
|
|
|
|
|
|
|
| |
MO_COFFSTUB. NFC.
These stubs should never be emitted for internal symbols, and
nothing in AsmPrinter ever actually use this value when producing
the stubs for COFF anyway.
llvm-svn: 341177
|
| |
|
|
|
|
|
|
|
|
|
| |
The runtime pseudo relocations can't handle the ARM format embedded
addresses in movw/movt pairs. By using stubs, the potentially
dllimported addresses can be touched up by the runtime pseudo relocation
framework.
Differential Revision: https://reviews.llvm.org/D51450
llvm-svn: 341176
|
| |
|
|
|
|
|
|
| |
v2f32)) when -x86-experimental-vector-widening-legalization is on.
We don't need to do our own widening, the generic legalizer can do it.
llvm-svn: 341174
|
| |
|
|
|
|
|
|
| |
-x86-experimental-vector-widening-legalization is in effect.
We aren't doing anything than what the generic legalizer will do so just let it do it.
llvm-svn: 341172
|
| |
|
|
|
|
|
| |
This doesn't really matter if clang is always emitting
the visibility as hidden by default.
llvm-svn: 341168
|
| |
|
|
| |
llvm-svn: 341165
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
management and materialization responsibility registration.
The setOverrideObjectFlagsWithResponsibilityFlags method instructs
RTDyldObjectlinkingLayer2 to override the symbol flags produced by RuntimeDyld with
the flags provided by the MaterializationResponsibility instance. This can be used
to enable symbol visibility (hidden/exported) for COFF object files, which do not
currently support the SF_Exported flag.
The setAutoClaimResponsibilityForObjectSymbols method instructs
RTDyldObjectLinkingLayer2 to claim responsibility for any symbols provided by a
given object file that were not already in the MaterializationResponsibility
instance. Setting this flag allows higher-level program representations (e.g.
LLVM IR) to be added based on only a subset of the symbols they provide, without
having to write intervening layers to scan and add the additional symbols. This
trades diagnostic quality for convenience however: If all symbols are enumerated
up-front then clashes can be detected and reported early. If this option is set,
clashes for the additional symbols may not be detected until late, and detection
may depend on the flow of control through JIT'd code.
llvm-svn: 341154
|
| |
|
|
|
|
| |
discussion
llvm-svn: 341147
|
| |
|
|
| |
llvm-svn: 341137
|
| |
|
|
|
|
|
|
|
|
|
| |
It has essentially the same benefit it has on 64-bit ARM: it
substantially reduces the number of constants used by large GEP
operations. Seems to be generally helpful across a few different
codebases I've tried.
Differential Revision: https://reviews.llvm.org/D51462
llvm-svn: 341136
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51516
llvm-svn: 341131
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Lowers away bitconverts between vector types. This CL depends
on D51383.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51498
llvm-svn: 341128
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Reuse the patterns from WebAssemblyInstrMemory.td.
Reviewers: aheejin, dschuff
Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D51383
llvm-svn: 341127
|
| |
|
|
| |
llvm-svn: 341122
|
| |
|
|
|
|
|
|
|
| |
$$Z appears between adjacent expanded parameter packs in the
same template instantiation. We don't need to print it, it's
only there to disambiguate between manglings that would otherwise
be ambiguous. So we just need to parse it and throw it away.
llvm-svn: 341119
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, the SafeStack analysis disallows out-of-bounds writes but not
out-of-bounds reads for mem intrinsics like llvm.memcpy. This could
cause leaks of pointers to the safe stack by leaking spilled registers/
frame pointers. Check for allocas used as source or destination pointers
to mem intrinsics.
Reviewers: eugenis
Reviewed By: eugenis
Subscribers: pcc, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D51334
llvm-svn: 341116
|
| |
|
|
|
|
|
|
|
|
|
| |
get_execution_seed returns a size_t which varies across platforms, but its
users actually always feed it into a uint64_t role so it makes sense to be
consistent.
Mostly this is just a tidy-up, but it also apparently allows PCH files to be
shared between Clang compilers built for 32-bit and 64-bit hosts.
llvm-svn: 341113
|