Expression evaluation allocates memory for storing intermediate data during evaluation. For it to work properly it has to be allocated within target's available address space, for example within first 0xFFFF bytes for the 16-bit MSP430. The memory for such targets can be very tightly packed, but not all targets support GetMemoryRegionInfo API to pick an unused region, like MSP430 with MSPDebug GDB server.
These settings allow the programmer to manually pick precisely where and how much memory to allocate for expression evaluation in order not to overlap with existing data in process memory.
Reviewed By: bulbazord
Differential Revision: https://reviews.llvm.org/D149262
The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.
There's no reason to create an entire new filespec to mutate and grab
data from when we can just grab the data directly.
Differential Revision: https://reviews.llvm.org/D149625
That patch adds a check for threadIndex being used with only threads
created by ThreadPoolExecutor. This helps catch two types of errors:
1. If a thread is created not by ThreadPoolExecutor its index may clash
with the index of another thread. Using threadIndex, in that case, may
lead to a data race.
2. Index of the main thread(threadIndex == 0) currently clashes with
the index of thread0 in ThreadPoolExecutor threads. That may lead
to a data race if main thread and thread0 are executed concurrently.
This patch allows execution tasks on the main thread only in case
parallel::strategy.ThreadsRequested == 1. In all other cases,
assertions check that threadIndex != UINT_MAX(i.e. that task
is executed on a thread created by ThreadPoolExecutor).
Differential Revision: https://reviews.llvm.org/D148916
In createPhysicalFileSystem, preserve the per-instance working
directory, even after the first call to getcwd fails.
rdar://108213753
Differential Revision: https://reviews.llvm.org/D149173
The purpose of this patch is to Implement registration of callback functions in the generic plugin by looking up corresponding callbacks in libomptarget. The overall design document is https://rice.app.box.com/s/pf3gix2hs4d4o1aatwir1set05xmjljc
Defined an object of type OmptDeviceCallbacksTy in the amdgpu plugin for holding the tool-provided callback functions. Implemented a global constructor in the plugin that creates a connector object to connect with libomptarget. The callbacks that are already registered with libomptarget are looked up and registered with the plugin.
Combined with an internal patch from Dhruva Chakrabarti, which fixes the OMPT initialization ordering.
Achieved through removal of the constructor attribute from ompt_init.
Patch from John Mellor-Crummey <johnmc@rice.edu>
With contributions from:
Dhruva Chakrabarti <Dhruva.Chakrabarti@amd.com>
Michael Halkenhaeuser <MichaelGerald.Halkenhauser@amd.com>
Differential Revision: https://reviews.llvm.org/D124070
In a link map, the input section name gives more information. See the updated
merge-entsize.s for an example. The output file is unchanged.
Compiler generated input sections with the SHF_MERGE flag have names such as
.rodata.str1.1 and .rodata.cstN, and are not affected by -fdata-sections.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D149466
Extends the pack/unpack generalization patterns to work for any packing
op with only full tiles. This produces a combination of rank-reduced
insert/extract slice ops paired with a transpose on the reduced shape,
similar to what the pattern currently produces for fully tiled
pack/unpacks. Note that only the outer dims are rank-reduced in this
pattern, leaving the shape of the inner tile intact.
Differential Revision: https://reviews.llvm.org/D147555
D21942 / 1128db8fe1 added support for
committing shadow memory on demand on Win 64-bit. The reason it is not
enabled on 32-bit wasn't clear but the page table overhead on Windows 7
may be a contributing factor.
In `AsanMapUnmapCallback::OnUnmap`, `FlushUnneededASanShadowMemory` is
called to release shadow memory. It calls `ReleaseMemoryPagesToOS`,
which had been a no-op on Windows, until D95892 /
81b1d3da09 in which it was changed to
unmap full pages that the memory region covers. This was done on both
32-bit and 64-bit.
AddressSanitizerInterface.GetHeapSizeTest appears to fail on i686
targets as a side effect of this. This test allocates and frees a huge
chunk of memory which causes shadow memory to be unmapped immediately.
When the test allocates the chunk of memory a second time, asan tries to
reuse the same shadow memory region, but because the shadow memory has
now been unmapped, it causes an access violation and crashes the test.
x86_64 is not affected, because the code that handles commiting shadow
memory on demand also handles this situation, allowing the test to work
without crashing.
Therefore, this patch changes `FlushUnneededASanShadowMemory` on Windows
to only release/unmap the shadow memory on x86_64 to stop this from
happening on i686.
Differential Revision: https://reviews.llvm.org/D149025
This was discovered while working on modules. They can't export
declarations with internal linkage.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D149593
The tosa-infer-shapes pass crashes when trying to infer the output shape
of tosa.equal when the input shape is unranked.
This is due to tosa-infer-shapes requiring at least information on the
base type of the resulting operation from inferReturnTypeComponents.
This change enhances EqualOp::inferReturnTypeComponents to always supply
the inferred elementType.
Reviewed By: eric-k256
Differential Revision: https://reviews.llvm.org/D149582
This reduces dependencies on `llvm-tblgen` so much.
`CodeGenTypes` depends on `Support` at the moment.
Be careful to append deps on this, since Targets' tablegens
depend on this.
Depends on D149024
Differential Revision: https://reviews.llvm.org/D148769
This is rework of;
- rG13e77db2df94 (r328395; MVT)
Since `LowLevelType.h` has been restored to `CodeGen`, `MachinveValueType.h`
can be restored as well.
Depends on D148767
Differential Revision: https://reviews.llvm.org/D149024
This is rework of;
- D30046 (LLT)
Since I have introduced `llvm-min-tblgen` as D146352, `llvm-tblgen`
may depend on `CodeGen`.
`LowLevlType.h` originally belonged to `CodeGen`. Almost all userse are
still under `CodeGen` or `Target`. I think `CodeGen` is the right place
to put `LowLevelType.h`.
`MachineValueType.h` may be moved as well. (later, D149024)
I have made many modules depend on `CodeGen`. It is consistent but
inefficient. It will be split out later, D148769
Besides, I had to isolate MVT and LLT in modmap, since
`llvm::PredicateInfo` clashes between `TableGen/CodeGenSchedule.h`
and `Transforms/Utils/PredicateInfo.h`.
(I think better to introduce namespace llvm::TableGen)
Depends on D145937, D146352, and D148768.
Differential Revision: https://reviews.llvm.org/D148767
This reverts commit e3b1083e00.
This was reverted because it breaks a number of libstdc++ examples, AND
required a workaround that causes hiding of legitimate bugs.
After importing variables, we do some checking to ensure that variables
marked read or write only, which have been marked exported (e.g.
because a referencing function has been exported), are on at least one
module's imports list. This is because the read or write only variables
will be internalized, so we need a copy any any module that references
it.
This checking is overly conservative in the case of linkonce_odr or
other linkage types where there can already be a duplicate copy in
existence in the importing module, which therefore wouldn't need to
import it. Loosen up the checking for these linkage types.
Fixes https://github.com/llvm/llvm-project/issues/62468.
Differential Revision: https://reviews.llvm.org/D149630
The MLIR SVE integration tests are now enabled in the
clang-aarch64-full-2stage buildbot under emulation (QEMU) and two of the
sparse integration tests are failing [1]:
* mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_sorted_coo.mlir
* mlir/test/Integration/Dialect/SparseTensor/CPU/sparse_spmm.mlir
The reason for this is the SVE RUN lines use plain 'lli' rather than the
'%lli_host_or_aarch64_cmd' substitution that's necessary to run under
emulation. The CI doesn't support SVE so the tests will SIGILL unless
run under emulation.
I should note the logs don't show a SIGILL, only the non-descript:
FileCheck error: '<stdin>' is empty.
but I expect this is what's actually happening.
https://lab.llvm.org/buildbot/#/builders/179/builds/6051/steps/12/logs/stdio
This patch addresses some of the flags and features that are currently
missing from the hermetic test support. This mostly just fixes the
`add_libc_test` option failing to find a few dependencies or missing
arguments from the previous unit test support.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D149629
For empty sections, RuntimeDyld always allocates 1 byte but leaves it
uninitialized. This causes the contents of some output sections to be
non-deterministic.
Note that this issue is also solved by D147544.
Fixes#59008
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D149243
This patch fixes a bug introduced by D142586, which landed as
434992c96e. The fix was to only look for alignments that are powers
of 2. See the new test case for details.
Reviewed By: jdoerfert, jhuber6
Differential Revision: https://reviews.llvm.org/D149490
This patch makes interface of AddressManager from DWARFLinker
to be compatible with AddressesMap from DWARFLinkerParallel.
This makes both linkers to be interchangeable.
Differential Revision: https://reviews.llvm.org/D147455
Since we don't always need the vendor extension to be in riscv_vector.td,
so it's better to make it be in separated header.
Depends on D148223 and D148680
Differential Revision: https://reviews.llvm.org/D148308
Assuming that the stack grows downwards, it is fine if the stack
pointer is exactly at the stacklet boundary. We should use
less-or-equal condition when deciding whether to skip new memory
allocation.
Differential Revision: https://reviews.llvm.org/D149315
For finding the last iteration of a loop, or the last section an
if condition is generated. Using scf::if can cause some lowering
issues since the code contained inside it can have branches. Using
fir::if instead ensures that the fir::if is lowered into branches
along with any code contained inside that can generate branches.
Fixes#62458.
Reviewed By: NimishMishra
Differential Revision: https://reviews.llvm.org/D149547
We just want to test whether the language switch works.
This is easier to control for libc++, since for bots building
the tests against libstdc++ we might not have the necessary
`<compare>` header available currently.
