| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Without this SelectionDAG could fail assertions when using the intrinsic
in a non-entry BB.
|
|
|
|
Internal label names never occur in the symbol table, so when using an
object streamer, there's no point in constructing these names and then
adding them to hash tables -- they are never visible in the output.
It's not possible to reuse createTempSymbol, because on BPF has a
different prefix for globals and basic blocks right now.
|
|
We use explicit template instantiation for these classes, so there
is no need to have the definition in the header. The places that
instantiate the method will include the PassManagerImpl.h file.
|
|
gep nuw can be null if and only if both the base pointer and offset
are null. Unlike the inbounds case this does not depend on whether
the null pointer is valid.
Proofs: https://alive2.llvm.org/ce/z/PLoqK5
|
|
|
|
Load from null is UB, load from pointer arg instead.
|
|
Previously, a symbol insertion requires (at least) three hash table
operations:
- Lookup/create entry in Symbols (main symbol table)
- Lookup NextUniqueID to deduplicate identical temporary labels
- Add entry to UsedNames, which is also used to serve as storage for the
symbol name in the MCSymbol.
All three lookups are done with the same name, so combining these into a
single table reduces the number of lookups to one. Thus, a pointer to a
symbol table entry can be passed to createSymbol to avoid a duplicate
lookup of the same name.
The new symbol table entry value is placed in a separate header to avoid
including MCContext in MCSymbol or vice versa.
|
|
|
|
Instruction-creation (#94226)
This patch simplifies instruction creation by replacing all overloads of
instruction constructors/Create methods that are identical other than
the Instruction *InsertBefore/BasicBlock *InsertAtEnd/BasicBlock::iterator
InsertBefore argument with a single version that takes an InsertPosition
argument. The InsertPosition class can be implicitly constructed from
any of the above, internally converting them to the appropriate
BasicBlock::iterator value which can then be used to insert the
instruction (or to not insert it if an invalid iterator is passed).
The upshot of this is that code will be deduplicated, and all callsites
will switch to calling the new unified version without any changes
needed to make the compiler happy. There is at least one exception to
this; the construction of InsertPosition is a user-defined conversion,
so any caller that was already relying on a different user-defined
conversion won't work. In all of LLVM and Clang this happens exactly
once: at clang/lib/CodeGen/CGExpr.cpp:123 we try to construct an alloca
with an AssertingVH<Instruction> argument, which must now be cast to an
Instruction* by using `&*`. If this is more common elsewhere, it could
be fixed by adding an appropriate constructor to InsertPosition.
|
|
|
|
(#89944)
The ABI mandates two things related to function calls:
- Function arguments must be sign- or zero-extended to the register
size by the caller.
- Return values must be sign- or zero-extended to the register size by
the callee.
As consequence, callees can assume that function arguments have been
extended and so can callers with regards to return values.
Here lies the problem: Nonsecure code might deliberately ignore this
mandate with the intent of attempting an exploit. It might try to pass
values that lie outside the expected type's value range in order to
trigger undefined behaviour, e.g. out of bounds access.
With the mitigation implemented, Secure code always performs extension
of values passed by Nonsecure code.
This addresses the vulnerability described in CVE-2024-0151.
Patches by Victor Campos.
---------
Co-authored-by: Victor Campos <victor.campos@arm.com>
|
|
|
|
|
|
|
|
|
|
Reverts the behavior introduced by 770393b while keeping the refactored
code.
Fixes a miscompile on AArch64, at the cost of a small regression on
AMDGPU.
#96146 opened to investigate the issue
|
|
There are only three actual uses of the section kind in MCSection:
isText(), XCOFF, and WebAssembly. Store isText() in the MCSection, and
store other info in the actual section variants where required.
ELF and COFF flags also encode all relevant information, so for these
two section variants, remove the SectionKind parameter entirely.
This allows to remove the string switch (which is unnecessary and
inaccurate) from createELFSectionImpl. This was introduced in
[D133456](https://reviews.llvm.org/D133456), but apparently, it was
never hit for non-writable sections anyway and the resulting kind was
never used.
|
|
Remove support for shl constant expressions, as part of:
https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179
|
|
Add same interfaces variants to the `Module::setModuleFlag` as the
`Module::addModuleFlag` has.
|
|
This patch reverts https://github.com/llvm/llvm-project/pull/81585 as
https://github.com/llvm/llvm-project/pull/78582 has been landed.
Now clang works well with reproducer
https://github.com/llvm/llvm-project/pull/79993#issuecomment-1936822679.
|
|
|
|
(#93481)
This change is a preliminary step to support trampolines on RISC-V. Trampolines are used by flang to implement obtaining the address of an internal program (i.e., a nested function in Fortran parlance).
In this change we lower `llvm.clear_cache` intrinsic on glibc targets to
`__riscv_flush_icache` which is what GCC is currently doing for Linux targets.
|
|
|
|
(Background: See the comment:
https://github.com/llvm/llvm-project/pull/92083#issuecomment-2168121729)
It looks like the hash function for 64bits integers are not very good:
```
static unsigned getHashValue(const unsigned long long& Val) {
return (unsigned)(Val * 37ULL);
}
```
Since the result is truncated to 32 bits. It looks like the higher 32
bits won't contribute to the result. So that `0x1'00000001` will have
the the same results to `0x2'00000001`, `0x3'00000001`, ...
Then we may meet a lot collisions in such cases. I feel it should
generally good to include higher 32 bits for hashing functions.
Not sure who's the appropriate reviewer, adding some people by
impressions.
|
|
Otherwise LinkGraph::dump output could change
(llvm/test/ExecutionEngine/JITLink/x86-64/COFF_pdata_strip.s) when
llvm::hash_value(StringRef) changes.
|
|
|
|
Otherwise llvm/test/TableGen/GlobalISelCombinerEmitter/type-inference.td
could fail when llvm::hash_value(StringRef) changes.
Fix #66377
|
|
Don't rely on the iteration order of DenseSet<StringRef>, which is not
guaranteed to be deterministic.
|
|
Otherwise llvm/test/LTO/X86/cfi_jt_aliases.ll could fail when
DenseMapInfo<StringRef> changes.
|
|
--show-region-summary etc (#96016)
|
|
ArrayRef can be implicitly constructed from a C array while inferring
its size.
|
|
Add a 128-bit xxhash function, following the existing
`llvm::xxh3_64bits` and `llvm::xxHash` implementations. Previously,
48e93f57f1ee914ca29aa31bf2ccd916565a3610 added support for
`llvm::xxh3_64bits`, which closely follows the upstream implementation
at https://github.com/Cyan4973/xxHash, with simplifications from Devin
Hussey's xxhash-clean.
However, it is desirable to have a larger 128-bit hash key for use cases
such as filesystem checksums where chance of collision needs to be
negligible.
So to that end this also ports over the 128-bit xxh3_128bits as
`llvm::xxh3_128bits`.
Testing:
- Add a test based on xsum_sanity_check.c in upstream xxhash.
|
|
Split off from https://github.com/llvm/llvm-project/pull/92555
and slightly generalized to more precisely check for a header mask.
Use it to replace manual checks in collectHeaderMasks.
|
|
This change is part of this proposal:
https://discourse.llvm.org/t/rfc-all-the-math-intrinsics/78294
This is part 1 of 4 PRs. It sets the ground work for adding the
intrinsics.
Add DXIL Lower for `acos`, `asin`, `atan`, `cosh`, `sinh`, and `tanh`
https://github.com/llvm/llvm-project/issues/70079
https://github.com/llvm/llvm-project/issues/70080
https://github.com/llvm/llvm-project/issues/70081
https://github.com/llvm/llvm-project/issues/70083
https://github.com/llvm/llvm-project/issues/70084
https://github.com/llvm/llvm-project/issues/95966
|
|
Fixes issue reported in: https://github.com/llvm/llvm-project/pull/94224
The recent commit above added an ilist_parent<ParentTy> option, which
added a parent pointer to the ilist_node_base type for the list. The
const methods for returning that parent pointer however were incorrectly
implemented, returning `const ParentPtrTy`, which is equivalent to
`ParentTy * const` rather than `const ParentTy *`. This patch fixes this
by passing around `ParentTy` in ilist's internal logic rather than
`ParentPtrTy`, removing the ability to have a `void*` parent pointer but
cleanly fixing this error.
|
|
Add a mechanism to specify constraints to the design document. These facilitate
specification of DXIL Op attributes that are predicated by Shader Model version.
|
|
|
|
`combineHashValue` is a custom bit mixer from 2008
(5fc8ab6d187aefbf1d2cbd36e191e675b14db8f6) used for std::pair and
std::tuple. It has a long dependency chain and slow. Replace it with
a simply multiply-xorshift style hash using a constant from
splitmix64[1]. abseil-cpp and carbon also use this style, but with
uint128 to probably get a lower avalanche bias. We don't use uint128 for
MSVC portability.
Measured time to compute [0,1000000000) values on an i7-11850H:
* old: 1.163s
* new: 0.427s
[1]: https://jonkagstrom.com/tuning-bit-mixers/index.html
Pull Request: https://github.com/llvm/llvm-project/pull/95970
|
|
DenseMap iteration order is not guaranteed to be deterministic.
Without the change,
llvm/test/Transforms/GlobalMerge/basic.ll could fail when
`combineHashValue` changes (#95970).
|
|
If the GN arg `sysroot` was set to a root-relative path like e.g.
`"//sysroot"`, we weren't rebasing it correctly, leading to
warnings from clang about it ignoring a non-existent sysroot.
Similar to 6073f87d7f160.
|
|
arm_mve_pred_v2i (#94847)
|
|
For interleave groups, we only generate a pointer for the start of the
interleave group (the instruction at the insert position). The other
addresses for other members are alreayd considered free, but so are
their operands, if they are only used in address computations for
other interleave group members.
|
|
This change builds on 0a357ad which supported non-constant strides in
howFarToZero, but used only context insensitive reasoning.
This change does two things:
1) Directly use context sensitive queries to prove facts established
before the loop. Note that we technically only need facts known
at the latch, but using facts known on entry is a conservative
approximation which will cover most everything.
2) For the non-zero check, we can usually prove non-zero from the
finite assumption implied by mustprogress. This eliminates the
need to do the context sensitive query in the common case.
|
|
script
|
|
|
|
If we have a urem expression, emitting it as a urem is significantly
better that letting the fully expansion kick in. We have the risk of a
udiv or mul which could have previously been shared, but loosing that
seems like a reasonable tradeoff for being able to round trip a urem w/o
modification.
|
|
|
|
|
|
Fix style errors accidentally introduced in PRs #87259 and #94245.
Reviewers: rorth, jrtc27, brad0, s-barannikov
Reviewed By: s-barannikov
Pull Request: https://github.com/llvm/llvm-project/pull/96019
|
