Craig Topper [Wed, 17 Aug 2022 02:56:33 +0000 (19:56 -0700)]
[RISCV] Reuse existing VT variable instead of calling getValueType() repeatedly. NFC
Yuanfang Chen [Wed, 17 Aug 2022 01:28:49 +0000 (18:28 -0700)]
[Clang] followup D128745, add a missing ClangABICompat check
Stella Stamenova [Wed, 17 Aug 2022 01:11:28 +0000 (18:11 -0700)]
Revert "[LLDB][NFC] Fix optons parsing and misc. reliability in CommandObjectThread"
This very much non-NFC change broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/22557
This reverts commit
461b410159426fdc6da77e0fb653737e04e0ebe9.
Jonas Devlieghere [Wed, 17 Aug 2022 00:53:34 +0000 (17:53 -0700)]
[lldb] Automatically unwrap parameter packs in template argument accessors
When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.
This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.
A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.
The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.
The original patch was written by Fred Riss almost 4 years ago.
Differential revision: https://reviews.llvm.org/D51387
Monk Chiang [Thu, 21 Jul 2022 02:30:43 +0000 (19:30 -0700)]
[RISCV] Add scheduling class for vector pseudo segment instructions.
Add scheduling resource for vector segment load/store instructions in D128886.
I miss to add scheduling resource for pseudo segment instructions.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D130222
David Blaikie [Mon, 15 Aug 2022 23:47:23 +0000 (23:47 +0000)]
DebugInfo: Remove auto return type representation support
Seems this complicated lldb sufficiently for some cases that it hasn't
been worth supporting/fixing there - and it so far hasn't provided any
new use cases/value for debug info consumers, so let's remove it until
someone has a use case for it.
(side note: the original implementation of this still had a bug (I
should've caught it in review) that we still didn't produce
auto-returning function declarations in types where the function wasn't
instantiatied (that requires a fix to remove the `if
getContainedAutoType` condition in
`CGDebugInfo::CollectCXXMemberFunctions` - without that, auto returning
functions were still being handled the same as member function templates
and special member functions - never added to the member list, only
attached to the type via the declaration chain from the definition)
Further discussion about this in D123319
This reverts commit
5ff992bca208a0e37ca6338fc735aec6aa848b72: [DEBUG-INFO] Change how we handle auto return types for lambda operator() to be consistent with gcc
This reverts commit
c83602fdf51b2692e3bacb06bf861f20f74e987f: [DWARF5][clang]: Added support for DebugInfo generation for auto return type for C++ member functions.
Differential Revision: https://reviews.llvm.org/D131933
Zequan Wu [Wed, 17 Aug 2022 00:01:41 +0000 (17:01 -0700)]
[LLDB][NativePDB] Add nullptr checking.
Maxim Schessler [Mon, 15 Aug 2022 18:44:06 +0000 (11:44 -0700)]
Libfuzzer fix for Ctrl + c not working with -fork and -ignore_crashes=1
In some cases running Libfuzzer in fork mode with -ignore_crashes=1 counts ctrl+c as crash and restarts.
Thread: https://github.com/google/oss-fuzz/issues/4547
Credit: Marcel Boehme <marcel.boehme@acm.org>
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D130990
Craig Topper [Tue, 16 Aug 2022 23:11:37 +0000 (16:11 -0700)]
[RISCV] Add test cases to show missed opportunity to fold (sub C, (xor (setcc), 1)). NFC
(sub C, (xori X, 1)) can be folded to (add X, C-1) if X is 0 or 1.
This would avoid the xori and in some cases remove an instruction
neede to materialize the constant.
Martin Sebor [Tue, 16 Aug 2022 23:10:10 +0000 (17:10 -0600)]
[InstCombine] convert second std::min argument to same type as first
Ensure both arguments to std::min have the same type in all data models.
Shoaib Meenai [Tue, 16 Aug 2022 23:24:42 +0000 (16:24 -0700)]
[compiler-rt] Build with C++17 explicitly
We've started using C++17 constructs in compiler-rt now (e.g.
string_view in ORC), but when using the bootstrapping build, we won't
inherit the C++ standard from LLVM, and compilation may fail if we
default to an older standard. Explicitly build compiler-rt with C++17 in
a standalone build, which matches what other subprojects (e.g. Clang and
LLD) do.
Eli Friedman [Tue, 16 Aug 2022 23:15:44 +0000 (16:15 -0700)]
Untangle the mess which is MachineBasicBlock::hasAddressTaken().
There are two different senses in which a block can be "address-taken".
There can be a BlockAddress involved, which means we need to map the
IR-level value to some specific block of machine code. Or there can be
constructs inside a function which involve using the address of a basic
block to implement certain kinds of control flow.
Mixing these together causes a problem: if target-specific passes are
marking random blocks "address-taken", if we have a BlockAddress, we
can't actually tell which MachineBasicBlock corresponds to the
BlockAddress.
So split this into two separate bits: one for BlockAddress, and one for
the machine-specific bits.
Discovered while trying to sort out related stuff on D102817.
Differential Revision: https://reviews.llvm.org/D124697
Yonghong Song [Tue, 9 Aug 2022 00:33:23 +0000 (17:33 -0700)]
[Clang][BPF]: Force sign/zero extension for return values in caller
Currently bpf supports calling kernel functions (x86_64, arm64, etc.)
in bpf programs. Tejun discovered a problem where the x86_64 func
return value (a unsigned char type) is stored in 8-bit subregister %al
and the other 56-bits in %rax might be garbage. But based on current
bpf ABI, the bpf program assumes the whole %rax holds the correct value
as the callee is supposed to do necessary sign/zero extension.
This mismatch between bpf and x86_64 caused the incorrect results.
To resolve this problem, this patch forced caller to do needed
sign/zero extension for 8/16-bit return values as well. Note that
32-bit return values already had sign/zero extension even without
this patch.
For example, for the test case attached to this patch:
$ cat t.c
_Bool bar_bool(void);
unsigned char bar_char(void);
short bar_short(void);
int bar_int(void);
int foo_bool(void) {
if (bar_bool() != 1) return 0; else return 1;
}
int foo_char(void) {
if (bar_char() != 10) return 0; else return 1;
}
int foo_short(void) {
if (bar_short() != 10) return 0; else return 1;
}
int foo_int(void) {
if (bar_int() != 10) return 0; else return 1;
}
Without this patch, generated call insns in IR looks like:
%call = call zeroext i1 @bar_bool()
%call = call zeroext i8 @bar_char()
%call = call signext i16 @bar_short()
%call = call i32 @bar_int()
So it is assumed that zero extension has been done for return values of
bar_bool()and bar_char(). Sign extension has been done for the return
value of bar_short(). The return value of bar_int() does not have any
assumption so caller needs to do necessary shifting to get correct
32bit values.
With this patch, generated call insns in IR looks like:
%call = call i1 @bar_bool()
%call = call i8 @bar_char()
%call = call i16 @bar_short()
%call = call i32 @bar_int()
There are no assumptions for return values of the above four function calls,
so necessary shifting is necessary for all of them.
The following is the objdump file difference for function foo_char().
Without this patch:
0000000000000010 <foo_char>:
2: 85 10 00 00 ff ff ff ff call -1
3: bf 01 00 00 00 00 00 00 r1 = r0
4: b7 00 00 00 01 00 00 00 r0 = 1
5: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
6: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000038 <LBB1_2>:
7: 95 00 00 00 00 00 00 00 exit
With this patch:
0000000000000018 <foo_char>:
3: 85 10 00 00 ff ff ff ff call -1
4: bf 01 00 00 00 00 00 00 r1 = r0
5: 57 01 00 00 ff 00 00 00 r1 &= 255
6: b7 00 00 00 01 00 00 00 r0 = 1
7: 15 01 01 00 0a 00 00 00 if r1 == 10 goto +1 <LBB1_2>
8: b7 00 00 00 00 00 00 00 r0 = 0
0000000000000048 <LBB1_2>:
9: 95 00 00 00 00 00 00 00 exit
The zero extension of the return 'char' value is done here.
Differential Revision: https://reviews.llvm.org/D131598
Craig Topper [Tue, 16 Aug 2022 22:50:24 +0000 (15:50 -0700)]
Recommit "[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine."
This time using N1 instead of N0 since N1 points to the original
setcc. This now affects scheduling as I expected.
Original commit message:
We change seteq<->setne but it doesn't change the semantics
of the setcc. We should keep original debug location. This is
consistent with visitXor in the generic DAGCombiner.
Craig Topper [Tue, 16 Aug 2022 22:46:21 +0000 (15:46 -0700)]
Revert "[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine."
This reverts commit
1380b21ceba7b7b19e960da5df68dcd5cba1b091.
I mixed up N0 and N1 and didn't do what I intended.
Martin Sebor [Wed, 27 Jul 2022 21:55:22 +0000 (15:55 -0600)]
[InstCombine] Add support for strlcpy folding
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D130666
Craig Topper [Tue, 16 Aug 2022 22:19:51 +0000 (15:19 -0700)]
[RISCV] Use setcc's original SDLoc when inverting it in performSUBCombine.
We change seteq<->setne but it doesn't change the semantics
of the setcc. We should keep original debug location. This is
consistent with visitXor in the generic DAGCombiner.
Siva Chandra Reddy [Tue, 16 Aug 2022 22:32:29 +0000 (22:32 +0000)]
[libc][Obvious] Rearrange few header targets to satisfy dependency order.
Slava Gurevich [Mon, 15 Aug 2022 08:51:49 +0000 (01:51 -0700)]
[LLDB][NFC] Fix optons parsing and misc. reliability in CommandObjectThread
* Improve reliability by checking return results for calls to FindLineEntryByAddress()
* Fix broken option parsing in SetOptionValue()
Differential Revision: https://reviews.llvm.org/D131983
Guozhi Wei [Tue, 16 Aug 2022 22:06:50 +0000 (22:06 +0000)]
[unittests/CodeGen] Remove unique_ptr from the result of createTargetMachine
The object contained in unique_ptr will be automatically deleted at the end of
the current scope. In createMachineFunction,
auto TM = createTargetMachine();
creates a TM contained in unique_ptr, a reference of the TM is stored in a
MachineFunction object, but at the end of the function, the TM is deleted, so
later access to the TM(and contained STI, TRI ...) through MachineFunction
object is invalid.
So we should not use unique_ptr<BogusTargetMachine> in functions
createMachineFunction and createTargetMachine.
Differential Revision: https://reviews.llvm.org/D131790
Craig Topper [Tue, 16 Aug 2022 21:39:41 +0000 (14:39 -0700)]
[RISCV] Remove C!=0 restriction from (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)).
While (sub 0, X) can use x0 for the 0, I believe (add X, -1) is
still preferrable. (addi X, -1) can be compressed, sub with x0 on
the LHS is never compressible.
Martin Sebor [Mon, 15 Aug 2022 16:06:12 +0000 (10:06 -0600)]
[InstCombine] Remove assumptions about int having 32 bits
Reviewed By: bjope
Differential Revision: https://reviews.llvm.org/D131731
Slava Gurevich [Mon, 15 Aug 2022 09:25:42 +0000 (02:25 -0700)]
[LLDB][NFC] Fix memory leak in IntstumentationRuntimeTSan.cpp
ConvertToStructuredArray() relies on its caller to deallocate the heap-allocated object pointer it returns. One of its call-sites, in GetRenumberedThreadIds(), fails to deallocate causing a memory/resource leak. Fix the memory leak by converting the return type to shared_ptr, and clean up the rest of the file to use the typedef-ed shared_ptr types for StructuredData for safety and consistency.
Differential Revision: https://reviews.llvm.org/D131900
Alexander Shaposhnikov [Tue, 16 Aug 2022 21:25:19 +0000 (21:25 +0000)]
[Intrinsics] Add initial support for NonNull attribute
Add initial support for NonNull attribute.
(https://github.com/llvm/llvm-project/issues/57113)
Test plan:
verify that for
__thread int x;
int main() {
int* y = &x;
return *y;
}
(with this patch) clang -O -fsanitize=null -S -emit-llvm -o -
doesn't emit a null-pointer check
Differential revision: https://reviews.llvm.org/D131872
Saleem Abdulrasool [Tue, 16 Aug 2022 21:22:27 +0000 (21:22 +0000)]
CodeGen: correct handling of debug info generation for aliases
When aliasing a static array, the aliasee is going to be a GEP which
points to the value. We should strip pointer casts before forming the
reference. This was occluded by the use of opaque pointers.
This problem has existed since the introduction of the debug info
generation for aliases in
b1ea0191a42074341847d767609f66a26b6d5a41. The
test case would assert due to the invalid cast with or without
`-no-opaque-pointers` at that revision.
Fixes: #57179
Peiming Liu [Tue, 16 Aug 2022 20:47:02 +0000 (20:47 +0000)]
[mlir][sparse] Refactoring: remove Operation * from the argument list in utility functions
This patch remove the Operation *op from the argument list in utility functions, and directly pass the Location instead of calling op->getLoc().
This should make the code more clear, as the utility function (logically) does not relies on the operation that we are currently rewriting, and they behave the same regardless of the operation.
Reviewed By: aartbik, wrengr
Differential Revision: https://reviews.llvm.org/D131991
Ben Langmuir [Tue, 16 Aug 2022 00:54:00 +0000 (17:54 -0700)]
[clang][deps] Compute command-lines for dependencies immediately
Instead of delaying the generation of command-lines to after all
dependencies are reported, compute them immediately. This is partly in
preparation for splitting the TU driver command into its constituent cc1
and other jobs, but it also just simplifies working with the compiler
invocation for modules if they are not "without paths".
Also change the computation of the default output path in
clang-scan-deps to scrape the implicit module cache from the
command-line rather than get it from the dependency, since that is now
unavailable at the time we make the callback.
Differential Revision: https://reviews.llvm.org/D131934
Craig Topper [Tue, 16 Aug 2022 21:08:38 +0000 (14:08 -0700)]
[RISCV] Don't fold (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)) if C-1 isn't simm12.
We still need to materialize the constant in a register and we
may not be removing all uses of the original constant so it may
increase code size.
Craig Topper [Tue, 16 Aug 2022 21:04:19 +0000 (14:04 -0700)]
[RISCV] Add more test cases for (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)). NFC
In these test cases we do the transform, but the immediate is too
large to form an ADDI so it didn't save any instructions.
If the constant is opaque or has additional users we shouldn't do
the transform if it doesn't form an ADDI.
Craig Topper [Tue, 16 Aug 2022 20:49:44 +0000 (13:49 -0700)]
[RISCV] Move test from setcc-logic.ll to select-const.ll. NFC
Also add setne version of the test.
Add some common prefixes to reduce number of identical CHECK lines.
Peiming Liu [Thu, 4 Aug 2022 20:50:55 +0000 (20:50 +0000)]
[mlir][sparse] Implements concatenate operation for sparse tensor
This patch implements the conversion rule for operation introduced in https://reviews.llvm.org/D131200.
Also contains integration test for correctness
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D131200
Siva Chandra Reddy [Tue, 16 Aug 2022 20:33:24 +0000 (20:33 +0000)]
[libc][Obvious] Convert an add_header target to add_header_library target.
Craig Topper [Tue, 16 Aug 2022 19:57:05 +0000 (12:57 -0700)]
[RISCV] (sub C, (setcc x, y, eq/neq)) -> (add C-1, (setcc x, y, neq/eq)) fold for FP setcc.
This introduce an xori in some cases. I don't believe it was the
intention of the original patch. This was an accident because
nonan FP equality compares also use SETEQ/SETNE.
Also pass the correct type to getSetCCInverse.
Craig Topper [Tue, 16 Aug 2022 19:35:48 +0000 (12:35 -0700)]
[RISCV] Add test cases to show where we inverted a fp setcc and introduced an extra xori.
In these tests we had (sub C, (seteq X, Y)) which we converted to
the (add (setne X, Y), C-1). We don't have a FNE compare instruction
so this created an XORI to invert an FEQ instruction.
This might be a good idea since it can save a constant materialization,
but does not appear to be the intention of the original patch.
Craig Topper [Tue, 16 Aug 2022 19:24:18 +0000 (12:24 -0700)]
[RISCV] Minor cleanups to performSUBCombine. NFC
-Rename variable NnzC -> N0C.
-Use SelectionDAG::getSetCC to reduce code.
-Use SDValue::getOperand instead of operator-> and SDNode::getOperand.
Initial steps to add another similar combine to this code.
Kazu Hirata [Tue, 16 Aug 2022 19:33:21 +0000 (12:33 -0700)]
[lldb] Fix warnings
This patch fixes:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.h:34:5:
error: default label in switch which covers all enumeration values
[-Werror,-Wcovered-switch-default]
and:
lldb/source/Plugins/Instruction/RISCV/EmulateInstructionRISCV.cpp:194:21:
error: comparison of integers of different signs: 'int' and 'size_t'
(aka 'unsigned long') [-Werror,-Wsign-compare]
Roy Jacobson [Tue, 16 Aug 2022 19:27:36 +0000 (22:27 +0300)]
[Sema] Fix friend destructor declarations after D130936
I accidentally broke friend destructor declarations in D130936.
Modify it to skip performing the destructor name check if we have a dependent friend declaration.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D131541
Sanjay Patel [Tue, 16 Aug 2022 18:37:41 +0000 (14:37 -0400)]
[FlattenCFG] avoid crash on malformed code
We don't have a dominator tree in this pass, so we
can't bail out sooner by checking for unreachable
code, but this is a minimal fix for the example in
issue #56875.
Lei Huang [Wed, 10 Aug 2022 21:43:29 +0000 (16:43 -0500)]
[NFC][PowerPC] Add missing NOCOMPAT checks for builtins-ppc-xlcompat.c
Followup patch to address request from https://reviews.llvm.org/D124093
Reviewed By: amyk
Differential Revision: https://reviews.llvm.org/D131622
Dmitri Gribenko [Tue, 16 Aug 2022 16:27:41 +0000 (18:27 +0200)]
[clang][dataflow] Use llvm::is_contained()
Reviewed By: samestep, xazax.hun
Differential Revision: https://reviews.llvm.org/D131975
Nicolas Miller [Tue, 16 Aug 2022 17:23:38 +0000 (10:23 -0700)]
Fix subrange liveness checking at rematerialization
This patch fixes an issue where an instruction reading a whole register would be moved during register allocation into a spot where one of the subregisters was dead.
The code to check whether an instruction can be rematerialized at a given point or not was already checking for subranges to ensure that subregisters are live, but only when the instruction being moved was using a subregister, this patch changes that so the subranges are checked even when the moved instruction uses the full register.
This patch also adds a case to the original test for the subrange checking that trigger the issue described above.
The original subrange checking code was introduced in this revision: https://reviews.llvm.org/D115278
And I've encountered this issue on AMDGPUs while working with DPC++: https://github.com/intel/llvm/issues/6209
Essentially the greedy register allocator attempts to move the following instruction:
```
%3961:vreg_64 = V_LSHLREV_B64_e64 3, %3078:vreg_64, implicit $exec
```
From `@3440` into the body of a loop `@16312`, but `%3078` has the following live ranges:
```
%3078 [2224r,2240r:0)[2240r,3488B:1)[16192B,38336B:1) 0@2224r 1@2240r L0000000000000003 [2224r,3440r:0) 0@2224r L000000000000000C [2240r,3488B:0)[16192B,38336B:0) 0@2240r
```
So `@16312e` `%3078.sub1` is alive but `%3078.sub0` is dead, so this instruction being moved there leads to invalid memory accesses as `3078.sub0` ends up being trashed and the result of this instruction is used as part of an address calculation for a load.
On the original ticket this issue showed up on gfx906 and gfx90a but not on gfx908, this turned out to be because on gfx908 instead of moving the shift instruction into the loop, its value is spilled into an ACC register, gfx906 doesn't have ACC registers and for gfx90a ACC registers are used like regular vector registers and so aren't used for spilling.
With this patch the original application from the DPC++ ticket works properly on gfx906, and the result of the shift instruction is correctly spilled instead of moving the instruction in the loop.
Original Author: npmiller
Reviewed by: rampitec
Submitted by: rampitec
Differential Revision: https://reviews.llvm.org/D131884
David Blaikie [Tue, 16 Aug 2022 17:43:40 +0000 (17:43 +0000)]
Revert "flang: Fix flang build with -Wctad-maybe-unsupported"
-Wctad-maybe-unsupported is now disabled for flang so these explicit
deduction guides are not required.
This reverts commit
248591aabee7fcc5246b67879b6a71b0bbbc0b9c.
David Blaikie [Tue, 16 Aug 2022 17:43:08 +0000 (17:43 +0000)]
Revert "Some more from-the-hip ctad-maybe-unsupported fixes for flang"
-Wctad-maybe-unsupported is now disabled for flang so these explicit
deduction guides are not required.
This reverts commit
ec3956b6e63c1524d6b024ba5db9ffcd7281ada0.
David Blaikie [Tue, 16 Aug 2022 17:42:45 +0000 (17:42 +0000)]
Disable -Wctad-maybe-unsupported in flang since it already uses the feature a lot
Zequan Wu [Tue, 16 Aug 2022 02:34:13 +0000 (19:34 -0700)]
[LLDB][NativePDB] Add nullptr checking.
Mark de Wever [Wed, 13 Jul 2022 17:24:12 +0000 (19:24 +0200)]
[libc++] Improve updating data files.
This changes makes it easier to update the Unicode data files used for
the Extended Graphme Clustering as added in D126971.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129668
Mark de Wever [Sat, 16 Jul 2022 15:03:27 +0000 (17:03 +0200)]
[libc++][format] Improve format buffer.
Allow bulk output operations on the buffer instead of adding one
code unit at a time. This has a huge performance benefit at the cost of
larger binary. This doesn't implement @vitaut's earlier suggestion to
avoid buffering for std::string when writing a strings. That can be done
in a follow-up patch.
There are some minor complications for the non-buffered format_to_n.
When writing one character at a time it's easy to detect when reaching
the limit n. This is solved by adding a small overhead for format_to_n.
When the next write would overflow it stores the data in the internal
buffer and copies that up-to n code units. The overhead isn't measured,
but it's expected to only be an issue for small values of n; for larger
values the general improvements will outweight the new overhead.
```
text data bss dec hex filename
349081 6096 440 355617 56d21 format.libcxx.out-baseline
344442 6088 440 350970 55afa formatted_size.libcxx.out-baseline
4567980 57272 424 4625676 46950c formatter_float.libcxx.out-baseline
718800 12472 488 731760 b2a70 formatter_int.libcxx.out-baseline
376341 6096 552 382989 5d80d format_to.libcxx.out-beaseline
370169 6096 440 376705 5bf81 format.libcxx.out
365530 6088 440 372058 5ad5a formatted_size.libcxx.out
4575116 57272 424 4632812 46b0ec formatter_float.libcxx.out
725936 12472 488 738896 b4650 formatter_int.libcxx.out
397429 6096 552 404077 62a6d format_to.libcxx.out
```
For very small strings the new method is slower, from 4 characters
there's already a small gain.
```
Comparing ./format.libcxx.out-baseline to ./format.libcxx.out
Benchmark Time CPU Time Old Time New CPU Old CPU New
--------------------------------------------------------------------------------------------------------------------------------
BM_format_string<char>/1 +0.0268 +0.0268 43 44 43 44
BM_format_string<char>/2 +0.0133 +0.0133 22 22 22 22
BM_format_string<char>/4 -0.0248 -0.0248 12 11 12 11
BM_format_string<char>/8 -0.0831 -0.0831 6 6 6 6
BM_format_string<char>/16 -0.2976 -0.2976 4 3 4 3
BM_format_string<char>/32 -0.4369 -0.4369 3 2 3 2
BM_format_string<char>/64 -0.6375 -0.6375 3 1 3 1
BM_format_string<char>/128 -0.7685 -0.7685 2 1 2 1
```
The int benchmark has benefits for the simple formatting, but shines for
the complex formatting:
```
Comparing ./formatter_int.libcxx.out-baseline to ./formatter_int.libcxx.out
Benchmark Time CPU Time Old Time New CPU Old CPU New
----------------------------------------------------------------------------------------------------------------------------------------------------
BM_Basic<uint32_t> -0.2307 -0.2307 60 46 60 46
BM_Basic<int32_t> -0.1985 -0.1985 61 49 61 49
BM_Basic<uint64_t> -0.3478 -0.3479 81 53 81 53
BM_Basic<int64_t> -0.3475 -0.3475 81 53 81 53
BM_BasicLow<__uint128_t> -0.3388 -0.3388 86 57 86 57
BM_BasicLow<__int128_t> -0.3431 -0.3431 86 57 86 57
BM_Basic<__uint128_t> -0.2822 -0.2822 236 170 236 170
BM_Basic<__int128_t> -0.3107 -0.3107 219 151 219 151
Integral_LocFalse_BaseBin_AlignNone_Int64 -0.5781 -0.5781 178 75 178 75
Integral_LocFalse_BaseBin_AlignmentLeft_Int64 -0.9231 -0.9231 1156 89 1156 89
Integral_LocFalse_BaseBin_AlignmentCenter_Int64 -0.9179 -0.9179 1107 91 1107 91
Integral_LocFalse_BaseBin_AlignmentRight_Int64 -0.9238 -0.9238 1147 87 1147 87
Integral_LocFalse_BaseBin_ZeroPadding_Int64 -0.9170 -0.9170 1137 94 1137 94
Integral_LocFalse_BaseBin_AlignNone_Uint64 -0.5923 -0.5923 175 71 175 71
Integral_LocFalse_BaseBin_AlignmentLeft_Uint64 -0.9251 -0.9251 1154 86 1154 86
Integral_LocFalse_BaseBin_AlignmentCenter_Uint64 -0.9204 -0.9204 1105 88 1105 88
Integral_LocFalse_BaseBin_AlignmentRight_Uint64 -0.9242 -0.9242 1125 85 1125 85
Integral_LocFalse_BaseBin_ZeroPadding_Uint64 -0.9232 -0.9232 1139 88 1139 88
Integral_LocFalse_BaseOct_AlignNone_Int64 -0.3241 -0.3241 100 67 100 67
Integral_LocFalse_BaseOct_AlignmentLeft_Int64 -0.9322 -0.9322 1166 79 1166 79
Integral_LocFalse_BaseOct_AlignmentCenter_Int64 -0.9251 -0.9251 1108 83 1108 83
Integral_LocFalse_BaseOct_AlignmentRight_Int64 -0.9303 -0.9303 1136 79 1136 79
Integral_LocFalse_BaseOct_ZeroPadding_Int64 -0.9264 -0.9264 1156 85 1156 85
Integral_LocFalse_BaseOct_AlignNone_Uint64 -0.3116 -0.3116 96 66 96 66
Integral_LocFalse_BaseOct_AlignmentLeft_Uint64 -0.9310 -0.9310 1168 81 1168 81
Integral_LocFalse_BaseOct_AlignmentCenter_Uint64 -0.9281 -0.9281 1128 81 1128 81
Integral_LocFalse_BaseOct_AlignmentRight_Uint64 -0.9299 -0.9299 1148 80 1148 80
Integral_LocFalse_BaseOct_ZeroPadding_Uint64 -0.9288 -0.9288 1153 82 1153 82
Integral_LocFalse_BaseDec_AlignNone_Int64 -0.3342 -0.3342 95 63 95 63
Integral_LocFalse_BaseDec_AlignmentLeft_Int64 -0.9360 -0.9360 1157 74 1157 74
Integral_LocFalse_BaseDec_AlignmentCenter_Int64 -0.9303 -0.9303 1128 79 1128 79
Integral_LocFalse_BaseDec_AlignmentRight_Int64 -0.9369 -0.9369 1164 73 1164 73
Integral_LocFalse_BaseDec_ZeroPadding_Int64 -0.9323 -0.9323 1157 78 1157 78
Integral_LocFalse_BaseDec_AlignNone_Uint64 -0.3198 -0.3198 93 63 93 63
Integral_LocFalse_BaseDec_AlignmentLeft_Uint64 -0.9351 -0.9351 1158 75 1158 75
Integral_LocFalse_BaseDec_AlignmentCenter_Uint64 -0.9298 -0.9298 1128 79 1128 79
Integral_LocFalse_BaseDec_AlignmentRight_Uint64 -0.9361 -0.9361 1157 74 1157 74
Integral_LocFalse_BaseDec_ZeroPadding_Uint64 -0.9333 -0.9333 1151 77 1151 77
Integral_LocFalse_BaseHex_AlignNone_Int64 -0.3020 -0.3020 89 62 89 62
Integral_LocFalse_BaseHex_AlignmentLeft_Int64 -0.9357 -0.9357 1174 75 1174 75
Integral_LocFalse_BaseHex_AlignmentCenter_Int64 -0.9319 -0.9319 1129 77 1129 77
Integral_LocFalse_BaseHex_AlignmentRight_Int64 -0.9350 -0.9350 1161 75 1161 75
Integral_LocFalse_BaseHex_ZeroPadding_Int64 -0.9293 -0.9293 1150 81 1150 81
Integral_LocFalse_BaseHex_AlignNone_Uint64 -0.3056 -0.3057 86 59 86 59
Integral_LocFalse_BaseHex_AlignmentLeft_Uint64 -0.9378 -0.9378 1174 73 1174 73
Integral_LocFalse_BaseHex_AlignmentCenter_Uint64 -0.9341 -0.9341 1129 74 1130 74
Integral_LocFalse_BaseHex_AlignmentRight_Uint64 -0.9361 -0.9361 1157 74 1157 74
Integral_LocFalse_BaseHex_ZeroPadding_Uint64 -0.9315 -0.9315 1147 79 1147 79
Integral_LocFalse_BaseHexUpper_AlignNone_Int64 -0.0019 -0.0019 91 90 91 90
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Int64 -0.9099 -0.9099 1162 105 1162 105
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Int64 -0.9041 -0.9041 1121 108 1121 108
Integral_LocFalse_BaseHexUpper_AlignmentRight_Int64 -0.9086 -0.9086 1162 106 1162 106
Integral_LocFalse_BaseHexUpper_ZeroPadding_Int64 -0.9057 -0.9057 1164 110 1164 110
Integral_LocFalse_BaseHexUpper_AlignNone_Uint64 +0.0110 +0.0110 86 87 86 87
Integral_LocFalse_BaseHexUpper_AlignmentLeft_Uint64 -0.9136 -0.9136 1161 100 1161 100
Integral_LocFalse_BaseHexUpper_AlignmentCenter_Uint64 -0.9078 -0.9078 1133 104 1133 104
Integral_LocFalse_BaseHexUpper_AlignmentRight_Uint64 -0.9132 -0.9132 1177 102 1177 102
Integral_LocFalse_BaseHexUpper_ZeroPadding_Uint64 -0.9091 -0.9091 1160 105 1160 105
```
Other benchmarks give similar results.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129964
Vitaly Buka [Tue, 16 Aug 2022 16:35:56 +0000 (09:35 -0700)]
[test][libcxx] Don't XFAIL passing test with HWASAN
Slava Zakharin [Thu, 14 Jul 2022 18:00:15 +0000 (11:00 -0700)]
[mlir][math] Added basic support for FPowI operation.
The operation computes pow(b, p), where 'b' is floating point
and 'p' is a signed integer. The result's type matches 'b' type.
The operands must have the same shape.
Differential Revision: https://reviews.llvm.org/D129811
Steven Wu [Tue, 16 Aug 2022 16:03:32 +0000 (09:03 -0700)]
[CMake] Cleanup the descriptions for gRPC options
As a followup to https://reviews.llvm.org/D131593, clean up gRPC related
option names and messages to make them more generic.
David Blaikie [Tue, 16 Aug 2022 16:03:30 +0000 (16:03 +0000)]
Some more from-the-hip ctad-maybe-unsupported fixes for flang
Simon Pilgrim [Tue, 16 Aug 2022 15:32:56 +0000 (16:32 +0100)]
[ValueTracking] computeKnownBits - attempt to use a branch condition feeding a phi to improve known bits range (PR38280)
If computeKnownBits encounters a phi node, and we fail to determine any known bits through direct analysis, see if the incoming value is part of a branch condition feeding the phi.
Handle cases where icmp(IncomingValue PRED Constant) is driving a branch instruction feeding that phi node - at the moment this only handles EQ/ULT/ULE predicate cases as they are the most straightforward to handle and most likely for branch-loop 'max upper bound' cases - we can extend this if/when necessary.
I investigated a more general icmp(LHS PRED RHS) KnownBits system, but the hard limits we put on value tracking depth through phi nodes meant that we were mainly catching constants anyhow.
Fixes the pointless vectorization in PR38280 / Issue #37628 (excessive unrolling still needs handling though)
Differential Revision: https://reviews.llvm.org/D131838
Emmmer [Tue, 16 Aug 2022 07:38:18 +0000 (15:38 +0800)]
[LLDB][RISCV] Make software single stepping work
Add:
- `EmulateInstructionRISCV`, which can be used for riscv32 and riscv64.
- Add unittests for EmulateInstructionRISCV.
Note: Compressed instructions set (RVC) was still not supported in this patch.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131759
Emmmer [Tue, 16 Aug 2022 07:37:23 +0000 (15:37 +0800)]
[LLDB] Handle possible resume thread error
In this switch case we didn't handle possible errors in `ResumeThread()`, it's hard to get helpful information when it goes wrong.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131946
Emmmer [Tue, 16 Aug 2022 07:35:38 +0000 (15:35 +0800)]
[LLDB] Fix possible nullptr exception
Some architectures do not have a flag register (like riscv).
In this case, we should set it to `baton.m_register_values.end()` to avoid nullptr exception.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D131945
Florian Hahn [Tue, 16 Aug 2022 15:29:15 +0000 (16:29 +0100)]
[PhaseOrdering] Add test showing excessive unrolling of vector loop.
Test cases based on #42332 showing excessive unrolling with both known
and runtime trip counts.
Arthur Eubanks [Mon, 15 Aug 2022 18:04:50 +0000 (11:04 -0700)]
[Windows] Put init_seg(compiler/lib) in llvm.global_ctors
Currently we treat initializers with init_seg(compiler/lib) as similar
to any other init_seg, they simply have a global variable in the proper
section (".CRT$XCC" for compiler/".CRT$XCL" for lib) and are added to
llvm.used. However, this doesn't match with how LLVM sees normal (or
init_seg(user)) initializers via llvm.global_ctors. This
causes issues like incorrect init_seg(compiler) vs init_seg(user)
ordering due to GlobalOpt evaluating constructors, and the
ability to remove init_seg(compiler/lib) initializers at all.
Currently we use 'A' for priorities less than 200. Use 200 for
init_seg(compiler) (".CRT$XCC") and 400 for init_seg(lib) (".CRT$XCL"),
which do not append the priority to the section name. Priorities
between 200 and 400 use ".CRT$XCC${Priority}". This allows for
some wiggle room for people/future extensions that want to add
initializers between compiler and lib.
Fixes #56922
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D131910
Fred Tingaud [Tue, 16 Aug 2022 15:09:55 +0000 (17:09 +0200)]
MSVC compatibility mode: fix error on unqualified templated base class initialization in case of partial specialization
I introduced a patch to handle unqualified templated base class
initialization in MSVC compatibility mode:
https://reviews.llvm.org/rGc894e85fc64dd8d83b460de81080fff93c5ca334
We identified a problem with this patch in the case where the base class
is partially specialized, which can lead to triggering an assertion in
the case of a mix between types and values.
The minimal test case is:
template <typename Type, int TSize> class Vec {};
template <int TDim> class Index : public Vec<int, TDim> {
Index() : Vec() {}
};
template class Index<0>;
The detailed problem is that I was using the
`InjectedClassNameSpecialization`, to which the class template arguments
were then applied in order. But in the process, we were losing all the
partial specializations of the base class and creating an index mismatch
between the expected and passed arguments.
Patch By: frederic-tingaud-sonarsource
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D130709
Danila Malyutin [Thu, 4 Aug 2022 07:08:05 +0000 (10:08 +0300)]
[RS4GC] Handle vectors of pointers in non-live clobbering
Fix crash when trying to unconditionally cast alloca type to PointerType
Differential Revision: https://reviews.llvm.org/D131146
Simon Pilgrim [Tue, 16 Aug 2022 14:34:39 +0000 (15:34 +0100)]
[InstCombine] known-phi-br.ll - remove multiuse handling from tests
Based off discussion with @spatel for D131838 - InstCombine will still canonicalize the predicates enough that the @use() multiuses aren't helping
Steve Merritt [Mon, 8 Aug 2022 14:40:11 +0000 (10:40 -0400)]
[CodeView] Use non-qualified names for static local variables
Static variables declared within a routine or lexical block should
be emitted with a non-qualified name. This allows the variables to
be visible to the Visual Studio watch window.
Differential Revision: https://reviews.llvm.org/D131400
Alexey Bataev [Mon, 15 Aug 2022 14:22:21 +0000 (07:22 -0700)]
[SLP]Fix PR51320: Try to vectorize single store operands.
Currently, we try to vectorize values, feeding into stores, only if
slp-vectorize-hor-store option is provided. We can safely enable
vectorization of the value operand of a single store in the basic block,
if the operand value is used only in store.
It should enable extra vectorization and should not increase compile
time significantly.
Fixes https://github.com/llvm/llvm-project/issues/51320
Differential Revision: https://reviews.llvm.org/D131894
David Spickett [Tue, 16 Aug 2022 13:50:37 +0000 (13:50 +0000)]
[LLVM][Debuginfod] Add missing thread include
One of our silent bots is currently failing:
https://lab.llvm.org/staging/#/builders/171/builds/169
With:
<...>/Debuginfod.cpp:298:23: error: no type named 'sleep_for' in namespace 'std::this_thread'
std::this_thread::sleep_for(Interval);
~~~~~~~~~~~~~~~~~~^
Add missing thread include to that file,
which is what all the other users of sleep_for do.
I think we are seeing this now because we disabled
llvm threading for this builder. Maybe debuginfod should account
for that but that's for another time.
Louis Dionne [Fri, 5 Aug 2022 17:49:39 +0000 (13:49 -0400)]
[clang][Darwin] Re-apply "Always set the default C++ Standard Library to libc++"
Newer SDKs don't even provide libstdc++ headers, so it's effectively
never valid to build for libstdc++ unless the user explicitly asks
for it (in which case they will need to provide include paths and more).
This is a re-application of
c5ccb78ade81 which had been reverted in
33171df9cc7f because it broke the Fuchsia CI bots. The issue was that
the test was XPASSing because it didn't fail anymore when the
CLANG_DEFAULT_CXX_LIB was set to libc++, which seems to be done for
Fuchsia. Instead, the test only fails if CLANG_DEFAULT_CXX_LIB is
set to libstdc++.
As a fly-by fix, also adjust the triple used by various tests to
something that is supported. Those tests were shown to fail on
internal bots.
Differential Revision: https://reviews.llvm.org/D131274
Zain Jaffal [Tue, 16 Aug 2022 13:07:43 +0000 (14:07 +0100)]
[instcombine] Test for zero initialisation optimisation of a product given fast flags
Precommit tests for D131672.
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D131757
Kevin P. Neal [Tue, 16 Aug 2022 12:45:36 +0000 (08:45 -0400)]
Fix build error: [FPEnv][EarlyCSE] Support for CSE when exception behavior is "ignore" or "maytrap" and the rounding mode is known.
This should fix these build bot errors:
Step 6 (build-check-mlir-build-only) failure: build (failure)
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(124): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(124): warning C4996: 'llvm::Optional<llvm::fp::ExceptionBehavior>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(129): warning C4996: 'llvm::Optional<llvm::RoundingMode>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(1386): warning C4996: 'llvm::Optional<llvm::fp::ExceptionBehavior>::getValue': Use value instead.
C:\buildbot\mlir-x64-windows-ninja\llvm-project\llvm\lib\Transforms\Scalar\EarlyCSE.cpp(1388): warning C4996: 'llvm::Optional<llvm::RoundingMode>::getValue': Use value instead.
YingChi Long [Mon, 15 Aug 2022 14:35:39 +0000 (22:35 +0800)]
[Sema] fix false -Wcomma being emitted from void returning functions
Fixes https://github.com/llvm/llvm-project/issues/57151
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131892
Kevin P. Neal [Tue, 16 Aug 2022 12:30:05 +0000 (08:30 -0400)]
[FPEnv][EarlyCSE] Support for CSE when exception behavior is "ignore" or "maytrap" and the rounding mode is known.
Previously we would only CSE constrained FP intrinsics in the default
floating point environment. Exception behavior of "strict" is still not
allowed since we are not allowed to remove any traps in that case.
There are no restrictions on CSE across function calls inside a function.
Differential Revision: https://reviews.llvm.org/D112256
Nikita Popov [Tue, 16 Aug 2022 12:16:31 +0000 (14:16 +0200)]
[cmake] Fix tablegen exports
This fixes some fallout from D131282. Currently, add_tablegen() will add the tablegen target to LLVM_EXPORTS and associates the install with LLVMExports. For non-standalone builds, this means that you end up with mlir-tblgen and clang-tblgen in LLVMExports.
However, these projects should instead be using MLIR_EXPORTS/MLIRTargets and CLANG_EXPORTS/ClangTargets. To fix this, add an extra EXPORT option and make use of get_target_export_arg() to create the correct export argument.
Reviewed By: ashay-github
Differential Revision: https://reviews.llvm.org/D131565
Karl Meakin [Tue, 16 Aug 2022 11:49:11 +0000 (12:49 +0100)]
[AArch64] Add `foldCSELOfCSEl` DAG combine
Differential Revision: https://reviews.llvm.org/D125504
Simon Pilgrim [Tue, 16 Aug 2022 11:05:13 +0000 (12:05 +0100)]
[InstSimplify] Add another and(x,c) case where the mask is redundant (and in fact can constant fold away)
Florian Hahn [Tue, 16 Aug 2022 11:21:49 +0000 (12:21 +0100)]
[LV] Use variables instead of hard-coded metadata IDs in tests.
Zain Jaffal [Tue, 16 Aug 2022 11:19:36 +0000 (12:19 +0100)]
[AArch64] Add support for 256-bit non temporal loads
Currenlty all temporal loads are mapped to `LDP` or `LDR`. This patch will map all the non temporal 256-bit loads into `LDNP`. Future patches should address other non-temporal loads.
Reviewed By: fhahn, dmgreen
Differential Revision: https://reviews.llvm.org/D131773
Clement Courbet [Wed, 9 Mar 2022 16:20:37 +0000 (17:20 +0100)]
[CFG] Fix crash on CFG building when deriving from a template.
Differential Revision: https://reviews.llvm.org/D121365
Victor Campos [Thu, 11 Aug 2022 14:21:49 +0000 (15:21 +0100)]
[ARM] Simplify the creation of escaped build attribute values
There is an existing mechanism to escape strings, therefore the
functions created to escape Tag_also_compatible_with values are not
really needed. We can simply use the pre-existing utilities.
Reviewed By: pratlucas
Differential Revision: https://reviews.llvm.org/D131680
Victor Campos [Tue, 12 Jul 2022 15:10:58 +0000 (16:10 +0100)]
[ARM] Parse Tag_also_compatible_with attribute
The ARM Attribute Parser used to parse the value of also_compatible_with
as it is, disregarding the way it is encoded.
This patch does a context aware parsing of the also_compatible_with
attribute. Additionally, some error handling is also done for incorrect
cases.
Reviewed By: pratlucas
Differential Revision: https://reviews.llvm.org/D130913
Bing1 Yu [Tue, 16 Aug 2022 08:42:08 +0000 (16:42 +0800)]
[X86] Fix a lowering issue of mask.compress which has undef float passthrough
Previously, LegaizeDAG didn't check mask.compress's passthrough might be float, and this lead to getConstant crash since it doesn't support fp
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D131947
Andre Vieira [Tue, 16 Aug 2022 09:15:32 +0000 (10:15 +0100)]
[TypePromotion] Only search for PHI + ZExt promotion of Integers
Differential Revision: https://reviews.llvm.org/D131948
Zain Jaffal [Tue, 16 Aug 2022 08:40:51 +0000 (09:40 +0100)]
[AArch64] Add tests to check for loop vectorization of non temporal loads
Reviewed By: fhahn
Differential Revision: https://reviews.llvm.org/D131899
David Spickett [Thu, 11 Aug 2022 09:22:00 +0000 (09:22 +0000)]
[LLDB][ARM] Remove unused LoadPseudoRegistersFromFrame function
https://reviews.llvm.org/D131658 identified a bug in this and
turns out it's not used anywhere.
Reviewed By: JDevlieghere, clayborg
Differential Revision: https://reviews.llvm.org/D131664
Sam McCall [Tue, 16 Aug 2022 08:26:25 +0000 (10:26 +0200)]
[pseudo] Style tweaks forgotten in D130337. NFC
Max Kazantsev [Tue, 16 Aug 2022 06:41:59 +0000 (13:41 +0700)]
Return "[SCEV] Use context to strengthen flags of BinOps"
This reverts commit
354fa0b48008eca701a110badd6974bf449df257.
Returning as is. The patch was reverted due to a miscompile, but
this patch is not causing it. This patch made it possible to infer
some nuw flags in code guarded by `false` condition, and then someone
else to managed to propagate the flag from dead code outside.
Returning the patch to be able to reproduce the issue.
Vitaly Buka [Tue, 16 Aug 2022 04:24:28 +0000 (21:24 -0700)]
[test][libcxx] Use own feature for HWAsan
Vitaly Buka [Tue, 16 Aug 2022 04:15:18 +0000 (21:15 -0700)]
[test][libcxx] Disable new.delete.array tests for HWAsan
gonglingqin [Tue, 16 Aug 2022 06:25:04 +0000 (14:25 +0800)]
[LoongArch] Add codegen support for fabs
Differential Revision: https://reviews.llvm.org/D131871
Weining Lu [Tue, 16 Aug 2022 05:37:43 +0000 (13:37 +0800)]
[LoongArch] Encode LoongArch specific ELF e_flags to binary by LoongArchTargetStreamer
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note:
There are several PRs [1][2][3] that may affect the e_flags.
After they got closed or merged, we should update the implementation here accordingly.
[1] https://github.com/loongson/LoongArch-Documentation/pull/33
[2] https://github.com/loongson/LoongArch-Documentation/pull/47
[2] https://github.com/loongson/LoongArch-Documentation/pull/61
Differential Revision: https://reviews.llvm.org/D130239
Chuanqi Xu [Tue, 16 Aug 2022 05:33:53 +0000 (13:33 +0800)]
[NFC] Add unittest for inline functions in modules
Johannes Reifferscheid [Thu, 11 Aug 2022 13:56:07 +0000 (15:56 +0200)]
Don't lower log1p(x) to log(1 + x).
The latter has accuracy issues around 0. The lowering in MathToLLVM is kept for now.
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D131676
Amir Ayupov [Tue, 16 Aug 2022 03:34:25 +0000 (20:34 -0700)]
[BOLT][NFC] Extend debug logging in analyzeJumpTable
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D131918
Kazu Hirata [Tue, 16 Aug 2022 03:33:10 +0000 (20:33 -0700)]
[ExecutionEngine] Fix a warning
This patch fixes the warning:
llvm/lib/ExecutionEngine/JITLink/ELF_i386.cpp:66:11: error: unused
type alias 'Base' [-Werror,-Wunused-local-typedef]
Danil Sidoruk [Tue, 16 Aug 2022 03:26:56 +0000 (20:26 -0700)]
[clang-format] Fix aligning of java-style declarations
- Modify TokenAnnotator to work fine with java-style array declarations.
- Add test for aligning of java declarations.
Fixes #55931.
Differential Revision: https://reviews.llvm.org/D129628
wanglian [Tue, 16 Aug 2022 02:01:08 +0000 (10:01 +0800)]
[SelectionDAG][NFC] Fix return type when used isConstantIntBuildVectorOrConstantInt
and isConstantFPBuildVectorOrConstantFP
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D131870
Kshitij Jain [Tue, 16 Aug 2022 01:39:34 +0000 (18:39 -0700)]
Re-apply "[JITLink] Introduce ELF/i386 backend " with correct authorship.
I (lhames) accidentally pushed
5f300397c6ae8fa7ca3547ec2b7a3cd844f3ed59 on
Kshitij Jain's behalf without updating the patch author first (my apologies
Kshitij!).
Re-applying with correct authorship.
https://reviews.llvm.org/D131347
Lang Hames [Tue, 16 Aug 2022 01:38:23 +0000 (18:38 -0700)]
Revert "[JITLink] Introduce ELF/i386 backend support for JITLink."
This reverts commit
5f300397c6ae8fa7ca3547ec2b7a3cd844f3ed59.
No functional issues, I just failed to correctly set authorship on the patch.
LLVM GN Syncbot [Tue, 16 Aug 2022 01:39:36 +0000 (01:39 +0000)]
[gn build] Port
5f300397c6ae
Lang Hames [Mon, 15 Aug 2022 04:13:37 +0000 (21:13 -0700)]
[JITLink] Introduce ELF/i386 backend support for JITLink.
This initial ELF/i386 JITLink backend enables JIT-linking of minimal ELF i386
object files. No relocations are supported yet.
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D131347
Ben Shi [Sat, 13 Aug 2022 12:23:25 +0000 (20:23 +0800)]
[Driver] Support linking to compiler-rt for target AVR
Reviewed By: aykevl
Differential Revision: https://reviews.llvm.org/D128133
David Blaikie [Tue, 16 Aug 2022 01:07:38 +0000 (01:07 +0000)]
flang: Fix flang build with -Wctad-maybe-unsupported
Shooting from the hip since I don't have a flang build locally, but
hopefully this works.
Jonas Devlieghere [Tue, 16 Aug 2022 00:37:34 +0000 (17:37 -0700)]
[lldb] Fetching symbols in the background with dsymForUUID
On macOS, LLDB uses the DebugSymbols.framework to locate symbol rich
dSYM bundles. [1] The framework uses a variety of methods, one of them
calling into a binary or shell script to locate (and download) dSYMs.
Internally at Apple, that tool is called dsymForUUID and for simplicity
I'm just going to refer to it that way here too, even though it can be
be an arbitrary executable.
The most common use case for dsymForUUID is to fetch symbols from the
network. This can take a long time, and because the calls to the
DebugSymbols.framework are blocking, it takes a while to launch the
process. This is expected and therefore many people don't use this
functionality, but instead use add-dsym when they want symbols for a
given frame, backtrace or module. This is a little faster because you're
only fetching symbols for the module you care about, but it's still a
slow, blocking operation.
This patch introduces a hybrid approach between the two. When
symbols.enable-background-lookup is enabled, lldb will do the equivalent
of add-dsym in the background for every module that shows up in the
backtrace but doesn't have symbols for. From the user's perspective
there is no slowdown, because the process launches immediately, with
whatever symbols are available. Meanwhile, more symbol information is
added over time as the background fetching completes.
[1] https://lldb.llvm.org/use/symbols.html
rdar://
76241471
Differential revision: https://reviews.llvm.org/D131328
Jonas Devlieghere [Tue, 16 Aug 2022 00:22:14 +0000 (17:22 -0700)]
[lldb] Flush the global thread pool in Debugger::Terminate
Use the Initialize/Terminate pattern for the global thread pool to make
sure it gets flushed during teardown.
Differential revision: https://reviews.llvm.org/D131407