In the past, when construct RISCVAsmBackend, MCTargetOptions.ABIName would be passed and stored in RISCVAsmBackend.
But MCTargetOptions.ABIName can only be specified by -target-abi xxx in command line, if the .ll file has target-abi attribute, the codegen module will ignore it. And the generated object file would have incorrect EFlags value.
https://github.com/llvm/llvm-project/issues/50591 also caused by this problem.
This patch override the AsmPrinter::emitFunctionEntryLabel function and use it to set the target abi value that get from .ll file's target-abi attribute. And storing the target-abi in RISCVTargetStreamer instead of RISCVAsmBackend.
Differential Revision: https://reviews.llvm.org/D121183
- Add `StructFieldRecord` and `StructRecord` to store API information
for structs
- Implement `VisitRecordDecl` in `ExtractAPIVisitor`
- Implement Symbol Graph serialization for struct records.
- Add test case for struct records.
Depends on D121873
Differential Revision: https://reviews.llvm.org/D122202
Add support for enum records
- Add `EnumConstantRecord` and `EnumRecord` to store API information for
enums
- Implement `VisitEnumDecl` in `ExtractAPIVisitor`
- Implement serializatin for enum records and `MemberOf` relationship
- Add test case for enum records
- Few other improvements
Depends on D122160
Differential Revision: https://reviews.llvm.org/D121873
Adds `--product-name=` flag to the clang driver. This gets forwarded to
cc1 only when we are performing a ExtractAPI Action. This is used to
populate the `name` field of the module object in the generated SymbolGraph.
Differential Revision: https://reviews.llvm.org/D122141
This takes a similar approach as b9b6938183, and shares some code.
The code sharing is limited as inlay hints wants to deduce the type of the
variable rather than the type of the `auto` per-se.
It drops support (in both places) for multiple instantiations yielding the same
type, as this is pretty rare and hard to build a nice API around.
Differential Revision: https://reviews.llvm.org/D120258
and, also update the function indirectCopyToAGPR() to ensure that it is called only on GFX908 sub-target.
Reviewed By: rampitec
Differential Revision: https://reviews.llvm.org/D122286
this patch adds lowering tests for
netsed where statements
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122323
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds some lowering tests for globals.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122322
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
-fsplit-machine-functions is an optimization in codegen phase. when -flto is use, clang generate IR bitcode in .o files, and linker will call into these codegen optimization passes. Current clang driver doesn't pass this option to linker when both -fsplit-machine-functions and -flto are used, so the optimization is silently ignored. My fix generates linker option -plugin-opt=-split-machine-functions for this case. It allows the linker to pass "split-machine-functions" to code generator to turn on that optimization. It works for both gold and lld.
Reviewed By: hoy, wenlei
Differential Revision: https://reviews.llvm.org/D121969
This patch adds lowering tests for IO related use cases.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122321
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds a lowering test for the namelist.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122318
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
EarlyCSE currently optimizes all MemoryUses upfront. However,
EarlyCSE only actually queries the clobbering memory access for
a subset of uses, namely those where a CSE candidate has already
been identified. Delaying use optimization to the clobber query
improves compile-time in practice.
This change is not NFC because EarlyCSE has a limit on the number
of clobber queries (EarlyCSEMssaOptCap), in which case it falls
back to the defining access. The defining access for uses will now
no longer coincide with the optimized access.
If there are performance regressions from this change, we should
be able to address them by raising this limit.
Differential Revision: https://reviews.llvm.org/D121987
Instead of asserting, fallback to emitting DWARF unwind info when an
attempt is made to output compact unwind info for a function with
multiple adjustments to the CFA offset.
Multiple adjustments of SP are common and with instruction precise
unwind tables these may translate into multiple `.cfi_def_cfa_offset`
directives.
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1302998
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D121017
Debian8 is too old to build LLVM project, the version
of GCC, CMake and python are lower than the requirements:
https://llvm.org/docs/GettingStarted.html#software
Debian10 is the earliest release that has software
packages that meet the above requirements.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D120826
The first attempt at this missed a validity check.
This version includes a test of the narrow source
type for modulo-16-bits.
Original commit message:
This is the IR counterpart to 370ebc9d9a
which provided a bswap narrowing fix for issue #53867.
Here we can be more general (although I'm not sure yet
what would happen for illegal types in codegen - too
rare to worry about?):
https://alive2.llvm.org/ce/z/3-CPfo
This will be more effective if we have moved the shift
after the bswap as proposed in D122010, but it is
independent of that patch.
Differential Revision: https://reviews.llvm.org/D122166
The intrinsic computes the sin, cosine values. By default they are lowered
to runtime calls to the pgmath library, for llvm lowering they are
lowered to llvm intrinsics. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D122320
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
There has been a lot of confusion on this in the past (see for
example https://reviews.llvm.org/D110634 and earlier revisions),
so let's try to get some clarity here. This patch specifies that
a) specifying a non-constant assumed alignment is explicitly
allowed and b) an invalid (non-power-of-two) alignment is not UB,
but rather converts it into an assumption that the pointer is null.
This change is done for two reasons:
a) Assume operand bundles are specifically used in cases where the
alignment is not known during frontend codegen (otherwise we'd just
use an align attribute), so rejecting this case doesn't make sense.
b) At least for aligned_alloc the C standard specifies that passing
an invalid alignment results in a null pointer, not undefined
behavior.
Differential Revision: https://reviews.llvm.org/D119414
The intrinsic computes the tan and hyperbolic sin, cosine values. By
default they are lowered to runtime calls to the math library. Not all
types are supported currently. The generic and llvm lowering does not
lower floating point types with kind greater than 8, the llvm lowering
does not support the complex types.
Note: tanh is not present in fir-dev hence ignoring for now. We can add
support after upstreaming is complete. sin and cos will come in separate
patches since they have llvm intrinsic lowering.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122264
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: William Moses <gh@wsmoses.com>
In D92191, a bunch of test cases were added to check `clang-scan-deps` works in `clang-cl` mode as well.
We don't need to duplicate all test cases, though. Testing the few special cases we have in `clang-scan-deps` for `clang-cl` should be good enough:
1. Deducing output path (and therefore target name in our make output).
2. Ignoring `-Xclang` arguments in step 1.
3. Deducing resource directory by invoking the compiler executuable.
This test de-duplicates the extra clang-cl test cases.
Reviewed By: dexonsmith, saudi
Differential Revision: https://reviews.llvm.org/D121812
This patch gets rid of the ridiculous relative path we use to invoke the `module-deps-to-rsp.py` script and creates proper lit substitution, cleaning up the tests.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D121525
The way the check is written is not compatible with opaque
pointers -- while we don't need to change the IR pointer type,
we do need to change the element type stored in the Address.
The one use check here is very misleading: At this point we should
actually have no uses, because the only possible use in llvm.used
was already dropped. But because the use in llvm.used is generally
bitcasted, we end up still having one dead use here.
What we actually want to check is that there are no live uses, for
which a helper has recently been added.
As we're going to reassign the initializer, we actually need the
value types to match, not just the pointer types. This is only
relevant with opaque pointers.
* Check for warnings instead of using -Werror, to avoid masking the
type of diagnostic emitted
* use different -verify labels instead of using conditional
compilation of diagnostic checks
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D122265
This patch some lowering tests for characters related operations.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122310
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch adds various lowering test
for calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122306
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Mats Petersson <mats.petersson@arm.com>
This patch adds some lowering tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122308
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds a lowering test for the C
interoperability.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122307
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch extends the support for C/C++ operators for SVE
types to allow one of the arguments to be a scalar, in which
case a vector splat is performed.
Differential Revision: https://reviews.llvm.org/D121829
`HeaderSearch` currently assumes `LookupFileCache` is eventually populated in `LookupFile`. However, that's not always the case with `-fms-compatibility` and its early returns.
This patch adds a defensive check that the iterator pulled out of the cache is actually valid before using it.
(This bug was introduced in D119721. Before that, the cache was initialized to `0` - essentially the `search_dir_begin()` iterator.)
Reviewed By: dexonsmith, erichkeane
Differential Revision: https://reviews.llvm.org/D122237
This change fixes a crash in RangedConstraintManager.cpp:assumeSym due to an
unhandled BO_Div case.
clang: <root>clang/lib/StaticAnalyzer/Core/RangedConstraintManager.cpp:51:
virtual clang::ento::ProgramStateRef
clang::ento::RangedConstraintManager::assumeSym(clang::ento::ProgramStateRef,
clang::ento::SymbolRef, bool):
Assertion `BinaryOperator::isComparisonOp(Op)' failed.
Reviewed By: NoQ
Differential Revision: https://reviews.llvm.org/D122277
This is a NFC refactoring to change makeIntValWithPtrWidth
and remove getZeroWithPtrWidth to use types when forming values to match
pointer widths. Some targets may have different pointer widths depending
upon address space, so this needs to be comprehended.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D120134
luxufan