This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.
Test failures have been fixed:
- ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4
- warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by
03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related)
- test-output-format.ll failure was spurious, build failed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93)
but passed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799)
which is before my revert
b4431b2d94...5ae99be037
Original commit message:
Depends on https://reviews.llvm.org/D142861.
Alternative to https://reviews.llvm.org/D137601.
xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.
Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.
Differential Revision: https://reviews.llvm.org/D142862
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
This reverts commit b861b1225380175a5a724e2a677754f5f74e5b0d.
This reverts commit 4be17641b05df1e63fa8e069af92676f1246eb83.
This patch wont build on some compilers on buildbot.
[TextAPI] Implement TBDv5 Reader
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields & follow up tests will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
The gABI prohibits multiple SH_SYMTAB sections. As a result,
llvm-objcopy was crashing in SymbolTableSection::removeSymbols(). This
patch fixes the issue by emitting an error if multiple SH_SYMTAB
sections are encountered when building an ELF object.
Fixes: https://github.com/llvm/llvm-project/issues/60448
Differential Revision: https://reviews.llvm.org/D143508
As a preparation for implementing DWARFv5 address ranges generation,
this patch refactors cloneAddressAttribute() method. It has special
handling for addresses which can be relocated in some unrelated value,
for applying relocations twice, for indexed addresses. Instead of
all these special handlings this patch uses general handling:
Read attribute value from InputDIE and apply PCOffset.
Another thing is that current handling of DW_FORM_addrx misses the
fact that relocations might be applied twice in some cases. This
patch fixes this problem also.
Differential Revision: https://reviews.llvm.org/D143269
This relands the commit previously reverted in
`8570bee53a8ce0c5d04bc11f288e19a457474c4c` due to failures on linux.
The problem was that the test executable was built with absolute
OSO prefix paths. This re-commit adds a modified version of the
executable that strips the absolute OSO prefix paths and makes
sure the test appends the OSO prefix appropriately (via the appropriate
dsymutil flags).
Differential Revision: https://reviews.llvm.org/D143458
This reverts commit ccee9b7839a182fc692a65f563abf76f81dd436c.
This started failing on Linux buildbots. The executable wasn't generated
correctly.
Differential Revision: https://reviews.llvm.org/D143458
**Summary**
After this patch, `dsymutil` will preserve `DW_TAG_imported_declarations`
entries in accelerator tables.
This allows consumers to resolve imported declarations even on
executables processsed through dsymutil.
This helps consumers, particularly LLDB's expression evaluator,
to resolve imported declarations (i.e., useful for namespace aliases
in C++) more efficiently.
**Testing**
* Added unit-test
Differential Revision: https://reviews.llvm.org/D143458
This isn't strictly needed, but this matches how MSVC lib.exe writes to
archives, so this makes llvm-lib more compatible and simplifies comparing
output between tools.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D143536
YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.
Differential Revision: https://reviews.llvm.org/D141848
Depends on https://reviews.llvm.org/D142861.
Alternative to https://reviews.llvm.org/D137601.
xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.
Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.
Differential Revision: https://reviews.llvm.org/D142862
Text editors can introduce spaces aligning the previous line's indentation. This crashes llvm-profdata. Added check to handle this case.
Reviewed By: snehasish
Differential Revision: https://reviews.llvm.org/D143369
Originally the test has a bug: in the input YAML `.symtab.dyn` section has a type
repeated twice with different values (SHT_SYMTAB and SHT_NOBITS). YAML parser
took SHT_NOBITS as a type of the section, so the test wasn't checking the desired
case.
This patch changes the test to verify that a section with SHT_SYMTAB type and
SHF_ALLOC flag is not removed when --strip-all-gnu flag present.
Differential Revision: https://reviews.llvm.org/D143086
We have a number of pending changes to update_test_checks.py
(and friends) that are essentially blocked on test churn:
If the output of UTC for an existing flag combination changes,
then the next time a test is regenerated, it will contain many
spurious changes. This makes changes to UTC default
behavior essentially impossible.
Examples of such changes are:
* D133943/D142373 want --function-signature to also check the
return type/attributes.
* D139006/D140212 want to make --function-signature the default
behavior.
* D142452 wants to add wildcards for block labels.
This patch tries to resolve this issue by adding a --version
argument, which works as follows:
* When regenerating an old test, the default version is 1.
* When generating a new test, the default version is the newest.
When an explicit version is specified, that of course wins.
This means that any currently existing tests will keep using
--version 1 format, while any new tests will automatically embed
--version N where N is the latest version, and then keep using
that test format from then on.
This patch only implements the --version flag without bumping
the default version, so it does not have any visible behavior
change by itself.
Differential Revision: https://reviews.llvm.org/D142473
'{', '}' and (conditionally) '*' were allowed at the start of a
statement. This behavior was copied from AsmParser, where they were
added to support Hexagon bundles (braces) and BFP memory instructions
(the star).
MASM dialect is x86-specific and does not allow these symbols to be
used at the beginning of an instruction.
Worth noting that '{' is a valid first character in AT&T syntax
(e.g. "{vex} vpmadd52huq ..."); MASM variant is to omit the braces.
Reviewed By: epastor
Differential Revision: https://reviews.llvm.org/D142321
The instruction property hasSideEffects relies on the presence of
tablegen isel patterns when constructing its value, unless
specifically overriden. Since adding SVE scheduling information
we've noticed this property flip-flop as isel patterns have been
updated. To make things consistent (and correct) this patch
explicitly sets the property for all SVE instructions.
This has resulted in the following notable changes:
* Normal load and store instructions no longer report having side
effects.
* All prefetch instructions correctly report having side effects.
* FFR related instructions continue to report having side effects.
This is likely overkill but I've chosen to remain cautious here.
* Most all integer instructions no longer report having side effects.
* Most all floating point instructions no longer report having side
effects, but do now report their potential for raising FP
exceptions. I do not know how to test the latter so I've again
took a caution route of taging all floating point instructions
except for DUPs.
* The conflict detection intrinsics now report they don't touch
memory.
NOTE: SVE isel makes significant use of psuedo instructions but
this patch makes no effort to update them.
NOTE: We'll need a similar patch for SME but without a scheduling
model it'll be harder to verify the results.
Differential Revision: https://reviews.llvm.org/D142122
An llc lit test used overaligned i8, apparently originating from the old DXIL data layout.
The new DXIL data layout uses naturally aligned i8.
llc ignores the data layout of a module and instead sets the data layout based
on the target. Change the data layout string in the test to match that target-derived
data layout.
Reduce by calling the resolver function at the use site, and inserting
an indirect call. Try to delete if there are no uses left over.
We should also probably try to do something about constantexpr uses;
perhaps treat them like aliases.
Let Propeller use specialized IDs for basic blocks, instead of MBB number.
This allows optimizations not just prior to asm-printer, but throughout the entire codegen.
This patch only implements the functionality under the new `LLVM_BB_ADDR_MAP` version, but the old version is still being used. A later patch will change the used version.
####Background
Today Propeller uses machine basic block (MBB) numbers, which already exist, to map native assembly to machine IR. This is done as follows.
- Basic block addresses are captured and dumped into the `LLVM_BB_ADDR_MAP` section just before the AsmPrinter pass which writes out object files. This ensures that we have a mapping that is close to assembly.
- Profiling mapping works by taking a virtual address of an instruction and looking up the `LLVM_BB_ADDR_MAP` section to find the MBB number it corresponds to.
- While this works well today, we need to do better when we scale Propeller to target other Machine IR optimizations like spill code optimization. Register allocation happens earlier in the Machine IR pipeline and we need an annotation mechanism that is valid at that point.
- The current scheme will not work in this scenario because the MBB number of a particular basic block is not fixed and changes over the course of codegen (via renumbering, adding, and removing the basic blocks).
- In other words, the volatile MBB numbers do not provide a one-to-one correspondence throughout the lifetime of Machine IR. Profile annotation using MBB numbers is restricted to a fixed point; only valid at the exact point where it was dumped.
- Further, the object file can only be dumped before AsmPrinter and cannot be dumped at an arbitrary point in the Machine IR pass pipeline. Hence, MBB numbers are not suitable and we need something else.
####Solution
We propose using fixed unique incremental MBB IDs for basic blocks instead of volatile MBB numbers. These IDs are assigned upon the creation of machine basic blocks. We modify `MachineFunction::CreateMachineBasicBlock` to assign the fixed ID to every newly created basic block. It assigns `MachineFunction::NextMBBID` to the MBB ID and then increments it, which ensures having unique IDs.
To ensure correct profile attribution, multiple equivalent compilations must generate the same Propeller IDs. This is guaranteed as long as the MachineFunction passes run in the same order. Since the `NextBBID` variable is scoped to `MachineFunction`, interleaving of codegen for different functions won't cause any inconsistencies.
The new encoding is generated under the new version number 2 and we keep backward-compatibility with older versions.
####Impact on Size of the `LLVM_BB_ADDR_MAP` Section
Emitting the Propeller ID results in a 23% increase in the size of the `LLVM_BB_ADDR_MAP` section for the clang binary.
Reviewed By: tmsriram
Differential Revision: https://reviews.llvm.org/D100808
generation code from DWARFLinker. It adds command line option:
--build-accelerator [none,DWARF]
Build accelerator tables(default: none)
=none - Do not build accelerators
=DWARF - Build accelerator tables according to the resulting DWARF version
DWARFv4: .debug_pubnames and .debug_pubtypes
DWARFv5: .debug_names
Differential Revision: https://reviews.llvm.org/D139638
The RMW instructions still need addressing, probably with a new 'WriteXCHGRMW' scheduler class.
Based off llvm-exegesis captures, confirmed with Agner + uops.info
Track min/max/avg access density (accesses per byte and accesses per
byte per lifetime second) metrics directly during profiling. This allows
more accurate use of these metrics in profile analysis and use, instead
of trying to compute them from already aggregated data in the profile.
This required regenerating some of the raw profile and executable inputs
for a few tests. While here, make the llvm-profdata memprof tests more
resilient to differences in things like memory mapping, timestamps and
cpu ids to make future test updates easier.
Differential Revision: https://reviews.llvm.org/D141558
According to DWARF5 specification and gnu specification for DWARF4 the offset
entry in the CU/TU Index is 32 bits. This presents a problem when
.debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially
corrupted.
This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to
reconstruct CU index in general, and TU index for DWARF5. This is a work around
until DWARF6 spec is finalized.
Next patch will change internal CU/TU struct to 64 bit, and change uses as
necessary. The plan is to land all the patches in one go after all are approved.
This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137882
class ConstantBuffer is added to save information for cbuffer.
Also add CBufferDataLayout to calculate the size for cbuffer.
Now always use legacy cbuffer layout.
https://reviews.llvm.org/D134998 will add control to disable legacy cbuffer layout.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D136031
These don't actually contain IR and don't use the correct IR comment
character. The assembler was not happy when I tried running tools over
every test in the suite.
D139603 (add option to llvm-profdata to reduce output profile size) contains test cases that are not cross-platform. Moving those tests to unit test and making sure the feature is callable from llvm library
Reviewed By: snehasish
Differential Revision: https://reviews.llvm.org/D141446
Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D139379
This reverts commit 4f575620d51032cf98424c9defafe4dfc8d66f45.
I realized the test wasn't very good and when fixed, shows the
reduction doesn't work correctly. Revert the change and keep the fixed
version of the test.
The current reduction logic tries to reproduce what a serial reduction
would produce, and just takes the first one that is still
interesting. We still have to wait for all others to complete though,
which at that point is just a waste.
This helps speed things up with long running reducers, which I
frequently have. e.g. for the added sleep test on my system, it took
about 8 seconds before this change and about 4 after.
https://reviews.llvm.org/D138953
Just avoid crashing for now, we should be able to replace the blockaddresses
themselves.
BlockAddress::handleOperandChangeImpl assumes it can cast to Function.
The verifier seems nonexistent and the langref isn't particularly explicit
on what's allowed as a blockaddress operand. As far as I can tell bugpoint
isn't doing anything to handle this.
Something low level is broken with BlockAddress handling,
demonstrated by reduce-functions-blockaddress-wrong-function.ll.
The BasicBlock destructor of the deleted function is triggering replacement
of blockaddresses for the kept function in some cases. I've only half debugged
this but it seems like blockaddress is handled too-specially compared to other
Constants. I have tentative patches to allow any constant to be a blockaddress
input, but having the verifier check if it's really a function/block.
https://reviews.llvm.org/D140909
This reverts commit 73712c8790a93c29e513f5e201f92ac5b2370cf9. It causes
a MemorySanitizer error in LLVM testsuite. See
the discussion on https://reviews.llvm.org/D137882 for details.
According to DWARF5 specification and gnu specification for DWARF4 the offset
entry in the CU/TU Index is 32 bits. This presents a problem when
.debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially
corrupted.
This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to
reconstruct CU index in general, and TU index for DWARF5. This is a work around
until DWARF6 spec is finalized.
Next patch will change internal CU/TU struct to 64 bit, and change uses as
necessary. The plan is to land all the patches in one go after all are approved.
This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D137882
Changed contribution data structure to 64 bit. I added the 32bit and 64bit
accessors to make it explicit where we use 32bit and where we use 64bit. Also to
make sure sure we catch all the cases where this data structure is used.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D139379
Allow user to specify `--output-size-limit=n` to cap the size of generated profile to be strictly under n. Functions with the lowest total sample count are dropped first if necessary. Due to using a heuristic, excessive functions may be dropped to satisfy the size requirement
Reviewed By: snehasish
Differential Revision: https://reviews.llvm.org/D139603
