| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
The 'LSL Rd' instruction is equivalent to 'ADD Rd, Rd'.
llvm-svn: 341278
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a TableGen warning about duplicate bit patterns.
SBR
===
This is an alias of 'ORI Rd, K'.
llvm-svn: 341277
|
| |
|
|
|
|
| |
The 'tst Rd' instruction is equivalent to 'and Rd, Rd'.
llvm-svn: 341276
|
| |
|
|
|
|
|
|
|
| |
The 'rol Rd' instruction is equivalent to 'adc Rd'.
This caused compile warnings from tablegen because of conflicting bits
shared between each instruction.
llvm-svn: 341275
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, rovka, kristof.beyls, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D49737
llvm-svn: 341271
|
| |
|
|
|
|
|
|
|
|
| |
Leverage existing logic in constant hoisting pass to transform constant GEP
expressions sharing the same base global variable. Multi-dimensional GEPs are
rewritten into single-dimensional GEPs.
Differential Revision: https://reviews.llvm.org/D51396
llvm-svn: 341269
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ModuleCount = InstrCount was incorrect. It should have been
InstrCount = ModuleCount. This was making it emit an extra, incorrect remark
for Print Module IR.
The test didn't catch this, because it didn't ensure that the only remark
output was from the desired pass. So, it was possible to have an extra remark
come through and not fail. Updated the test so that we ensure that the last
remark that's output comes from the desired pass. This is done by ensuring
that whatever is being read after the last remark is YAML output rather than
some incorrect garbage.
llvm-svn: 341267
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D51555
llvm-svn: 341266
|
| |
|
|
| |
llvm-svn: 341264
|
| |
|
|
|
|
|
|
| |
These intrinsics use the same implementation as PTEST intrinsics, but use vXi1 vectors.
New clang builtins will be accompanying them shortly.
llvm-svn: 341259
|
| |
|
|
|
|
|
|
|
| |
In basic block, loop, and function passes, we already have a function that
we can use to emit optimization remarks. We can use that instead of searching
the module for the first suitable function (that is, one that contains at
least one basic block.)
llvm-svn: 341253
|
| |
|
|
|
|
|
| |
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
|