merge #8
Merged
merge #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduce an off-by default `-Winvalid-utf8` warning that detects invalid UTF-8 code units sequences in comments. Invalid UTF-8 in other places is already diagnosed, as that cannot appear in identifiers and other grammar constructs. The warning is off by default as its likely to be somewhat disruptive otherwise. This warning allows clang to conform to the yet-to be approved WG21 "P2295R5 Support for UTF-8 as a portable source file encoding" paper. Reviewed By: aaron.ballman, #clang-language-wg Differential Revision: https://reviews.llvm.org/D128059
…nsulation Instead of marking private symbols with internal_linkage (which leads to one copy per translation unit -- rather wasteful), use an ABI tag that gets rev'd with each libc++ version. That way, we know that we can't have name collisions between implementation-detail functions across libc++ versions, so we'll never violate the ODR. However, within a single program, each symbol still has a proper name with external linkage, which means that the linker is free to deduplicate symbols even across TUs. This actually means that we can guarantee that versions of libc++ can be mixed within the same program without ever having to take a code size hit, and without having to manually opt-in -- it should just work out of the box. Differential Revision: https://reviews.llvm.org/D127444
Vectors are defined to be tightly packed, regardless of the element type. The AsmPrinter didn't realize this, and was allocating extra padding. Fixes llvm/llvm-project#49286 Fixes llvm/llvm-project#53246 Fixes llvm/llvm-project#55522 Differential Revision: https://reviews.llvm.org/D129164
…cking local debuginfo. This library implements the class `DebuginfodCollection`, which scans a set of directories for binaries, classifying them according to whether they contain debuginfo. This also provides the `DebuginfodServer`, an `HTTPServer` which serves debuginfod's `/debuginfo` and `/executable` endpoints. This is intended as the final new supporting library required for `llvm-debuginfod`. As implemented here, `DebuginfodCollection` only finds ELF binaries and DWARF debuginfo. All other files are ignored. However, the class interface is format-agnostic. Generalizing to support other platforms will require refactoring of LLVM's object parsing libraries to eliminate use of `report_fatal_error` ([[ https://github.com/llvm/llvm-project/blob/main/llvm/lib/Object/WasmObjectFile.cpp#L74 | e.g. when reading WASM files ]]), so that the debuginfod daemon does not crash when it encounters a malformed file on the disk. The `DebuginfodCollection` is tested by end-to-end tests of the debuginfod server (D114846). Reviewed By: mysterymath Differential Revision: https://reviews.llvm.org/D114845
The length of valid codepoints was incorrectly calculated which was not caught before because the absence of tests for the valid codepoints scenario. Differential Revision: https://reviews.llvm.org/D129223
This adds special-case treatment for parameter packs in make_unique-like functions to forward parameter names to inlay hints. The parameter packs are being resolved recursively by traversing the function body of forwarding functions looking for expressions matching the (std::forwarded) parameters expanded from a pack. The implementation checks whether parameters are being passed by (rvalue) reference or value and adds reference inlay hints accordingly. The traversal has a limited recursion stack depth, and recursive calls like std::make_tuple are cut off to avoid hinting duplicate parameter names. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D124690
This reverts commit 4174f0c. Also revert follow-up "[Clang] Fix invalid utf-8 detection" This reverts commit bf45e27. The second commit broke tests, see comments on https://reviews.llvm.org/D129223, and it sounds like the first commit isn't valid without the second one. So reverting both for now.
Silence warning from MSVC when handling ##__VA_ARGS Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D129227
Reviewed By: ktras Differential Revision: https://reviews.llvm.org/D128957
The revision makes a start with implementing expand/collapse reshaping for sparse tensors. When either source or destination is sparse, but other is dense, the "cheap" dense reshape can be used prior to converting from or to a sparse tensor. Note1 sparse to sparse reshaping is still TBD. Note2 in the long run, we may want to implement a "view" into a sparse tensor so that the operation remains cheap and does not require data shuffling Reviewed By: wrengr Differential Revision: https://reviews.llvm.org/D129031
The removed CHECK configurations are tested as well below, modulo the dce/instcombine runs. This makes them redundant, and removing them removes a substantial amount of uneeded checks.
An ENDFILE statement executed when a non-advancing READ has left the unit in the middle of a record must truncate the file at that position. Differential Revision: https://reviews.llvm.org/D129019
In folding and in the runtime library for real MOD/MODULO(A,P), detect overflow from the division A/P and return a properly signed zero result. (When A/P overflows and both A and P are finite numbers with nonzero P, the quotient would be a large integer when rounded to the precision of the floating-point representation.) Differential Revision: https://reviews.llvm.org/D129020
When Fw.d output editing takes place with directed rounding, make sure that nonzero values that would normally be converted to zero round up (or down, depending on the sign) to a scaled 1. Differential Revision: https://reviews.llvm.org/D129021
Bug fix to avoid assert crashing when generating remarks for GVN crashing.
Intention of assert is correct but ignores edge case of instructions being equivalent.
Reduced input that causes crash when remarks are turned on:
```
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64-apple-macosx12.0.0"
define ptr @ReplaceWithTidy(ptr %zz_hold) {
cond.end480.us:
%0 = load ptr, ptr null, align 8
store ptr %0, ptr %0, align 8
store ptr null, ptr %zz_hold, align 8
%1 = load ptr, ptr %0, align 8
store ptr %1, ptr null, align 8
ret ptr null
}
```
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D129235
…uilders=1 Per @RRiddle, we do not want to require `skipDefaultBuilders=0` per se; that is, even though the `assemblyFormat`-generated parser requires a builder with the same prototype as the default-builder, that prototype could instead be implemented via custom `builders`. This differential reduces the FatalError introduced in D128555 to a non-fatal Warning instead, so that users can still be informed of the error condition (rather than waiting for the C++ compiler to fail). Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D129234
Some files cannot be parsed on their own as they for example require a macro to be defined. To avoid spurious failures of clang-tidy, exclude such files from the code style checks. Remove spirv.hpp from the list as it is no longer in the tree. Original commit: KhronosGroup/SPIRV-LLVM-Translator@0974907
This change is incomplete, and will not properly convert every single LLVM IR file to SPIR-V. However, it will convert many files. Areas that are known to require more investigation: * ptr-valued extractvalue, especially from cmpxchg instructions * return values of functions * llvm.*.annotation support * function pointer extensions * pointer types in structs Original commit: KhronosGroup/SPIRV-LLVM-Translator@21fee92
Substitution rules in Itanium mangled names are unfortunately more complex and harder to parse than they should be, and there were two bugs that cropped in the current implementation (as found by running c++filt on the resulting names and discovering that they didn't demangle correctly). The first bug was that unqualified names double-registered the underlying pointer type. A mangled pointer type like PU3AS419__spirv_DeviceEvent should generate three substitutable names: * 19__spirv_DeviceEvent [a user-defined type gets an entry] * U3AS419__spirv_DeviceEvent [qualifiers of a pointer get an entry] * PU3AS419__spirv_DeviceEvent [the pointer as a whole gets an entry] However, if there's no qualifiers--we get a P19__spirv_DeviceEvent instead-- the original code was still adding multiple entries as follows: * 19__spirv_DeviceEvent [a user-defined type gets an entry] * 19__spirv_DeviceEvent [qualifiers of a pointer, but there are none!] * P19__spirv_DeviceEvent [the pointer as a whole gets an entry] The second bug is in the representation of the block pointer type for kernels: this is mangled as U13block_pointerFvvE. This type actually gets two entries: * FvvE [void(void) function type] * U13block_pointerFvvE [block_pointer-qualified function type] We weren't adding any entries for either of these types, causing later type entries to be offset by two. With this patch, these type entries *still* aren't added, so the mangling is incorrect if multiple block types are present in a function declaration. Since such functions don't exist for OpenCL/SPIR-V, it's okay that these cases are not correctly handled. Original commit: KhronosGroup/SPIRV-LLVM-Translator@9b280f4
* Implement support for @llvm.sadd.sat intrinsic. * Rename LowerSaddWithOverflow to LowerSaddIntrinsics. Original commit: KhronosGroup/SPIRV-LLVM-Translator@0af7e64
Emit (in OCLToSPIRV) and decode (in SPIRVToOCL) the SignExtend and ZeroExtend Image Operands introduced by SPIR-V version 1.4 to preserve signedness of image read and write operations. This allows distinguishing between e.g. `read_imagei` and `read_imageui` and enables a lossless LLVM -> SPIR-V -> LLVM conversion for those OpenCL builtins. Before SPIR-V 1.4, there was no way to represent the signedness of the image operations and llvm-spirv defaulted to signed. This commit leaves that behaviour unchanged if llvm-spirv's maximum version is set to SPIR-V 1.3 or below. Add the `--spirv-max-version=1.3` flag to some tests that rely on the old behaviour. Original commit: KhronosGroup/SPIRV-LLVM-Translator@bb4ead0
* [SYCL] Fail on kernel lambda size mismatch Some host-compilers may create lambdas with captures that do not match the ones used when extracting kernel descriptors. The compiler does not currently have a stable way of handling these cases, so instead this PR adds a static assertion that the sizes match with a message informing about the limitation. Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
…ning integral types (#6405) Adds bitwise group collective functions for signed and unsigned versions of types char, short and long. Changes to test suite in intel/llvm-test-suite#1077.
…ntel (#6415) It had been deprecated before. I don't think it's an ABI break but it is definitely an API break and we still need to increment major version in the next release.
This should resolve the issues with: https://lab.llvm.org/buildbot/#/builders/92/builds/29439
When calling `piEnqueueEventsWaitWithBarrier` while using the level zero backend, the barrier is only inserted into an available command list. However, this leaves other command lists unaffected. This commit fixes this unexpected behavior by making later command-lists insert a barrier on events from `piEnqueueEventsWaitWithBarrier` until they finish. The resulting event will be either the result of a single barrier, if events were passed to `piEnqueueEventsWaitWithBarrier`, or a wait on generic barriers on all queues if no events were passed to `piEnqueueEventsWaitWithBarrier`.
This reverts commit 4256e4e. This change enabled a test that is failing on Windows, so I'm leaving it out of this week's pulldown.
Reverts #6386 so that experimental/builtins.hpp is included in sycl.hpp. This avoids users being required to include this header when using printf or experimental math functions. Corresponding update here: intel/llvm-test-suite#1076.
…6422) - Kernel launching API for ESIMD_EMULATOR is updated in order to remove dependency on std::vector type - Download URL for pre-built CM_EMU library package is updated accordingly
LLVM: llvm/llvm-project@132d711 SPIRV-LLVM-Translator: KhronosGroup/SPIRV-LLVM-Translator@18d1f41
raaiq1
pushed a commit
that referenced
this pull request
Jul 18, 2022
…ned form
The DWARF spec says:
Any debugging information entry representing the declaration of an object,
module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
DW_AT_decl_column attributes, each of whose value is an unsigned integer
^^^^^^^^
constant.
If however, a producer happens to emit DW_AT_decl_file /
DW_AT_decl_line using a signed integer form, llvm-dwarfdump crashes,
like so:
(... snip ...)
0x000000b4: DW_TAG_structure_type
DW_AT_name ("test_struct")
DW_AT_byte_size (136)
DW_AT_decl_file (llvm-dwarfdump: (... snip ...)/llvm/include/llvm/ADT/Optional.h:197: T& llvm::optional_detail::OptionalStorage<T, true>::getValue() &
[with T = long unsigned int]: Assertion `hasVal' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/rocm/llvm/bin/llvm-dwarfdump ./testsuite/outputs/gdb.rocm/lane-pc-vega20/lane-pc-vega20-kernel.so
#0 0x000055cc8e78315f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x000055cc8e780d3d SignalHandler(int) Signals.cpp:0:0
#2 0x00007f8f2cae8420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#3 0x00007f8f2c58d00b raise /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#4 0x00007f8f2c56c859 abort /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:81:7
#5 0x00007f8f2c56c729 get_sysdep_segment_value /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:509:8
#6 0x00007f8f2c56c729 _nl_load_domain /build/glibc-SzIz7B/glibc-2.31/intl/loadmsgcat.c:970:34
#7 0x00007f8f2c57dfd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#8 0x000055cc8e58ceb9 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2e0eb9)
#9 0x000055cc8e58bec3 llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int, llvm::DIDumpOptions) const (/opt/rocm/llvm/bin/llvm-dwarfdump+0x2dfec3)
#10 0x000055cc8e5b28a3 llvm::DWARFCompileUnit::dump(llvm::raw_ostream&, llvm::DIDumpOptions) (.part.21) DWARFCompileUnit.cpp:0:0
Likewise with DW_AT_call_file / DW_AT_call_line.
The problem is that the code in llvm/lib/DebugInfo/DWARF/DWARFDie.cpp
dumping these attributes assumes that
FormValue.getAsUnsignedConstant() returns an armed optional. If in
debug mode, we get an assertion line the above. If in release mode,
and asserts are compiled out, then we proceed as if the optional had a
value, running into undefined behavior, printing whatever random
value.
Fix this by checking whether the optional returned by
FormValue.getAsUnsignedConstant() has a value, like done in other
places.
In addition, DWARFVerifier.cpp is validating DW_AT_call_file /
DW_AT_decl_file, but not AT_call_line / DW_AT_decl_line. This commit
fixes that too.
The llvm-dwarfdump/X86/verify_file_encoding.yaml testcase is extended
to cover these cases. Current llvm-dwarfdump crashes running the
newly-extended test.
"make check-llvm-tools-llvm-dwarfdump" shows no regressions, on x86-64
GNU/Linux.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D129392
raaiq1
pushed a commit
that referenced
this pull request
Nov 8, 2022
Found by msan -fsanitize-memory-use-after-dtor.
==8259==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x55dbec54d2b8 in dtorRecord(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:150:22
#1 0x55dbec54bfcf in dtorArrayDesc(clang::interp::Block*, char*, clang::interp::Descriptor*) clang/lib/AST/Interp/Descriptor.cpp:97:7
#2 0x55dbec508578 in invokeDtor clang/lib/AST/Interp/InterpBlock.h:79:7
#3 0x55dbec508578 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:55:19
#4 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
#5 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
#6 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22
#7 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
#8 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
#9 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40
#10 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7
#11 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38
#12 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7
#13 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27
#14 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3
#15 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8
#16 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11
intel#17 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
intel#18 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
intel#19 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
intel#20 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
intel#21 0x7f9be07fa632 in __libc_start_main
intel#22 0x55dbe6a702e9 in _start
Member fields were destroyed
#0 0x55dbe6a7da5d in __sanitizer_dtor_callback_fields compiler-rt/lib/msan/msan_interceptors.cpp:949:5
#1 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:479:7
#2 0x55dbec5094ac in ~SmallVectorImpl llvm/include/llvm/ADT/SmallVector.h:612:3
#3 0x55dbec5094ac in llvm::SmallVector<clang::interp::Record::Base, 8u>::~SmallVector() llvm/include/llvm/ADT/SmallVector.h:1207:3
#4 0x55dbec508e79 in clang::interp::Record::~Record() clang/lib/AST/Interp/Record.h:24:7
#5 0x55dbec508612 in clang::interp::Program::~Program() clang/lib/AST/Interp/Program.h:49:26
#6 0x55dbec50657a in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
#7 0x55dbec50657a in std::__msan::unique_ptr<clang::interp::Program, std::__msan::default_delete<clang::interp::Program>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
#8 0x55dbec5035a1 in clang::interp::Context::~Context() clang/lib/AST/Interp/Context.cpp:27:22
#9 0x55dbebec1daa in operator() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:55:5
#10 0x55dbebec1daa in std::__msan::unique_ptr<clang::interp::Context, std::__msan::default_delete<clang::interp::Context>>::~unique_ptr() third_party/crosstool/v18/stable/toolchain/bin/../include/c++/v1/__memory/unique_ptr.h:261:7
#11 0x55dbebe285f9 in clang::ASTContext::~ASTContext() clang/lib/AST/ASTContext.cpp:1038:40
#12 0x55dbe941ff13 in llvm::RefCountedBase<clang::ASTContext>::Release() const llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:101:7
#13 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:159:38
#14 0x55dbe94353ef in release llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:224:7
#15 0x55dbe94353ef in ~IntrusiveRefCntPtr llvm/include/llvm/ADT/IntrusiveRefCntPtr.h:191:27
#16 0x55dbe94353ef in clang::CompilerInstance::setASTContext(clang::ASTContext*) clang/lib/Frontend/CompilerInstance.cpp:178:3
intel#17 0x55dbe95ad0ad in clang::FrontendAction::EndSourceFile() clang/lib/Frontend/FrontendAction.cpp:1100:8
intel#18 0x55dbe9445fcf in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) clang/lib/Frontend/CompilerInstance.cpp:1047:11
intel#19 0x55dbe6b3afef in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:266:25
intel#20 0x55dbe6b13288 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) clang/tools/driver/cc1_main.cpp:250:15
intel#21 0x55dbe6b0095f in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) clang/tools/driver/driver.cpp:319:12
intel#22 0x55dbe6aff41c in clang_main(int, char**) clang/tools/driver/driver.cpp:395:12
intel#23 0x7f9be07fa632 in __libc_start_main
intel#24 0x55dbe6a702e9 in _start
raaiq1
pushed a commit
that referenced
this pull request
Nov 8, 2022
For the following program,
$ cat t.c
struct t {
int (__attribute__((btf_type_tag("rcu"))) *f)();
int a;
};
int foo(struct t *arg) {
return arg->a;
}
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
......
#5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
#6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
#7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
#8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
#9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
......
The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar
|-ParenType 0x8861480 'int ()' sugar
| `-FunctionNoProtoType 0x8861450 'int ()' cdecl
| `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.
To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().
Differential Revision: https://reviews.llvm.org/D136807
raaiq1
pushed a commit
that referenced
this pull request
Nov 15, 2022
…ction selection. Before this patch: - For `r = or op0, op1`, `tryBitfieldInsertOpFromOr` combines it to BFI when 1) one of the two operands is bit-field-positioning or bit-field-extraction op; and 2) bits from the two operands don't overlap After this patch: - Right before OR is combined to BFI, evaluates if ORR with left-shifted operand is better. A motivating example (https://godbolt.org/z/rnMrzs5vn, which is added as a test case in `test_orr_not_bfi` in `CodeGen/AArch64/bitfield-insert.ll`) For IR: ``` define i64 @test_orr_not_bfxil(i64 %0) { %2 = and i64 %0, 127 %3 = lshr i64 %0, 1 %4 = and i64 %3, 16256 %5 = or i64 %4, %2 ret i64 %5 } ``` Before: ``` lsr x8, x0, #1 and x8, x8, #0x3f80 bfxil x8, x0, #0, #7 ``` After: ``` ubfx x8, x0, #8, #7 and x9, x0, #0x7f orr x0, x9, x8, lsl #7 ``` Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D135102
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.