| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
(cherry picked from commit 0e8608b3c38886c224d252c6b126c804645b7761)
|
|
|
|
| |
(cherry picked from commit d73eed42d1dcba06a5b793346f6e3eed0c7f41ac)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.
This is problematic because arrays may be large, and instantiation
depth is limited.
This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.
(cherry picked from commit c6eb584c64872fbb779df14acd31c1f3947f6e52)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PowerPC hits an assertion due to somewhat the same reason as https://reviews.llvm.org/D70975.
Though there are already some hack, it still failed with some case, when the operand 0 is NOT
a const fp, it is another fma that with const fp. And that const fp is negated which result in multi-uses.
A better fix is to check the uses of the negated const fp. If there are already use of its negated
value, we will have benefit as no extra Node is added.
Differential revision: https://reviews.llvm.org/D75501
(cherry picked from commit 3906ae387f0775dfe4426e4336748269fafbd190)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
L is meant to support the second word used by 32b calling conventions for 64b arguments.
This is required for build 32b PowerPC Linux kernels after upstream
commit 334710b1496a ("powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'")
Thanks for the report from @nathanchance, and reference to GCC's
implementation from @segher.
Fixes: pr/46186
Fixes: https://github.com/ClangBuiltLinux/linux/issues/1044
Reviewers: echristo, hfinkel, MaskRay
Reviewed By: MaskRay
Subscribers: MaskRay, wuzish, nemanjai, hiraditya, kbarton, steven.zhang, llvm-commits, segher, nathanchance, srhines
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D81767
(cherry picked from commit 2d8e105db6bea10a6b96e4a094e73a87987ef909)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The UnwindHelp object is used during exception handling by runtime
code. It must be findable from a fixed offset from FP.
This change allocates the UnwindHelp object as a fixed object (as is
done for x86_64) to ensure that both the generated code and runtime
agree on the location of the object.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45346
Differential Revision: https://reviews.llvm.org/D77016
(cherry picked from commit 494abe139a9aab991582f1b3f3370b99b252944c)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generated code for a funclet can have an add to sp in the epilogue
for which there is no corresponding sub in the prologue.
This patch removes the early return from emitPrologue that was
preventing the sub to sp, and instead conditionalizes the appropriate
parts of the rest of the function.
Fixes https://bugs.llvm.org/show_bug.cgi?id=45345
Differential Revision: https://reviews.llvm.org/D77015
(cherry picked from commit 522b4c4b88a5606b0074926e8658e7fede97c230)
|
| |
|
|
|
|
|
|
|
|
| |
When the FP exists, the FP base CFI directive offset should take the size of variable arguments into account.
Differential Revision: https://reviews.llvm.org/D73862
(cherry picked from commit 64f417200e1020305f28f3c1e40691585f50f6ad)
|
|
|
|
|
|
|
|
|
|
| |
Provides an assembly implementation of muldi3 for RISC-V, to solve bug 43388.
Since the implementation is the same as for mulsi3, that code was moved to
`riscv/int_mul_impl.inc` and is now reused by both `mulsi3.S` and `muldi3.S`.
Differential Revision: https://reviews.llvm.org/D80465
(cherry picked from commit e31ccee1b01acf703889312ee86023ff87bd39fe)
|
|
|
|
|
|
|
|
|
|
|
| |
Since i32 is not legal in riscv64,
it always promoted to i64 before emitting lib call and
for conversions like float/double to int and float/double to unsigned int
wrong lib call was emitted. This commit fix it using custom lowering.
Differential Revision: https://reviews.llvm.org/D80526
(cherry picked from commit 7622ea5835f0381a426e504f4c03f11733732b83)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPRs on RV64
Summary:
This patch fixed the error of counting the remaining FPRs. Complex floating-point
values should be passed by two FPRs for the hard-float ABI. If no two FPRs are
available, it should be passed via a 64-bit GPR (fp+fp). `ArgFPRsLeft` is only
decreased one while the type is complex floating-point. It causes two floating-point
values in the complex are passed separately by two GPRs.
Reviewers: asb, luismarques, lenary
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, s.egerton, pzheng, sameer.abuasal, apazos, evandro, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79770
(cherry picked from commit 7ee479a760e0a4402b4eb7fb6168768a44f66945)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the comparison argument used for ATOMIC_CMP_XCHG is legalised
with GetPromotedInteger, which leaves the upper bits of the value
undefind. Since this is used for comparing in an LR/SC loop with a
full-width comparison, we must sign extend it on RISC-V.
This is related to https://reviews.llvm.org/D58829, which solved the
issue for ATOMIC_CMP_SWAP_WITH_SUCCESS, but not the simpler
ATOMIC_CMP_SWAP.
This patch is a modified form of
616289ed29225c0ddfe5699c7fdf42a0fcbe0ab4 by Jessica Clarke. It localises
the changes to LegalizeIntegerTypes and avoids adding a new virtual
method to TargetLowering to avoid changing the ABI of libLLVM.so.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D68391 added tests that check scenarios where no RISC-V GCC toolchain is
supposed to be detected. When running the tests on RISC-V hosts the system's
GCC toolchain will be detected, and the tests will fail. This patch adds a
`--gcc-toolchain` option pointing to a path where no GCC toolchain is
present, ensuring that the tests are run under the expected conditions, and
therefore are able to pass in all test environments.
Differential Revision: https://reviews.llvm.org/D75061
(cherry picked from commit 91f7f0d8e3ef2b6be07bc9621de075ff11c730c9)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
@nikic raised an issue on D75936 that the added complexity to the O0 pipeline was causing noticeable slowdowns for `-O0` builds. This patch addresses the issue by adding a pass with equal security properties, but without any optimizations (and more importantly, without the need for expensive analysis dependencies).
Reviewers: nikic, craig.topper, mattdr
Reviewed By: craig.topper, mattdr
Differential Revision: https://reviews.llvm.org/D80964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After finding all such gadgets in a given function, the pass minimally inserts
LFENCE instructions in such a manner that the following property is satisfied:
for all SOURCE+SINK pairs, all paths in the CFG from SOURCE to SINK contain at
least one LFENCE instruction. The algorithm that implements this minimal
insertion is influenced by an academic paper that minimally inserts memory
fences for high-performance concurrent programs:
http://www.cs.ucr.edu/~lesani/companion/oopsla15/OOPSLA15.pdf
The algorithm implemented in this pass is as follows:
1. Build a condensed CFG (i.e., a GadgetGraph) consisting only of the following components:
-SOURCE instructions (also includes function arguments)
-SINK instructions
-Basic block entry points
-Basic block terminators
-LFENCE instructions
2. Analyze the GadgetGraph to determine which SOURCE+SINK pairs (i.e., gadgets) are already mitigated by existing LFENCEs. If all gadgets have been mitigated, go to step 6.
3. Use a heuristic or plugin to approximate minimal LFENCE insertion.
4. Insert one LFENCE along each CFG edge that was cut in step 3.
5. Go to step 2.
6. If any LFENCEs were inserted, return true from runOnFunction() to tell LLVM that the function was modified.
By default, the heuristic used in Step 3 is a greedy heuristic that avoids
inserting LFENCEs into loops unless absolutely necessary. There is also a
CLI option to load a plugin that can provide even better optimization,
inserting fewer fences, while still mitigating all of the LVI gadgets.
The plugin can be found here: https://github.com/intel/lvi-llvm-optimization-plugin,
and a description of the pass's behavior with the plugin can be found here:
https://software.intel.com/security-software-guidance/insights/optimized-mitigation-approach-load-value-injection.
Differential Revision: https://reviews.llvm.org/D75937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gadgets
Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph.
More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK).
Also adds a new target feature to X86: +lvi-load-hardening
The feature can be added via the clang CLI using -mlvi-hardening.
Differential Revision: https://reviews.llvm.org/D75936
|
|
|
|
|
|
| |
not enabled with LVI-CFI
Differential Revision: https://reviews.llvm.org/D77427
|
|
|
|
|
|
| |
`MBB.back()` could segfault if `MBB.empty()`. Fixed by checking for `MBB.empty()` in the loop.
Differential Revision: https://reviews.llvm.org/D77584
|
|
|
|
|
|
|
|
|
| |
Injection (LVI) Gadgets"
This reverts commit c74dd640fd740c6928f66a39c7c15a014af3f66f.
Reverting to address coding standard issues raised in post-commit
review.
|
|
|
|
|
|
|
|
|
| |
Injection (LVI)"
This reverts commit 62c42e29ba43c9d79cd5bd2084b641fbff6a96d5
Reverting to address coding standard issues raised in post-commit
review.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After finding all such gadgets in a given function, the pass minimally inserts
LFENCE instructions in such a manner that the following property is satisfied:
for all SOURCE+SINK pairs, all paths in the CFG from SOURCE to SINK contain at
least one LFENCE instruction. The algorithm that implements this minimal
insertion is influenced by an academic paper that minimally inserts memory
fences for high-performance concurrent programs:
http://www.cs.ucr.edu/~lesani/companion/oopsla15/OOPSLA15.pdf
The algorithm implemented in this pass is as follows:
1. Build a condensed CFG (i.e., a GadgetGraph) consisting only of the following components:
-SOURCE instructions (also includes function arguments)
-SINK instructions
-Basic block entry points
-Basic block terminators
-LFENCE instructions
2. Analyze the GadgetGraph to determine which SOURCE+SINK pairs (i.e., gadgets) are already mitigated by existing LFENCEs. If all gadgets have been mitigated, go to step 6.
3. Use a heuristic or plugin to approximate minimal LFENCE insertion.
4. Insert one LFENCE along each CFG edge that was cut in step 3.
5. Go to step 2.
6. If any LFENCEs were inserted, return true from runOnFunction() to tell LLVM that the function was modified.
By default, the heuristic used in Step 3 is a greedy heuristic that avoids
inserting LFENCEs into loops unless absolutely necessary. There is also a
CLI option to load a plugin that can provide even better optimization,
inserting fewer fences, while still mitigating all of the LVI gadgets.
The plugin can be found here: https://github.com/intel/lvi-llvm-optimization-plugin,
and a description of the pass's behavior with the plugin can be found here:
https://software.intel.com/security-software-guidance/insights/optimized-mitigation-approach-load-value-injection.
Differential Revision: https://reviews.llvm.org/D75937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gadgets
Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph.
More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK).
Also adds a new target feature to X86: +lvi-load-hardening
The feature can be added via the clang CLI using -mlvi-hardening.
Differential Revision: https://reviews.llvm.org/D75936
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding a pass that replaces every ret instruction with the sequence:
pop <scratch-reg>
lfence
jmp *<scratch-reg>
where <scratch-reg> is some available scratch register, according to the
calling convention of the function being mitigated.
Differential Revision: https://reviews.llvm.org/D75935
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pass replaces each indirect call/jump with a direct call to a thunk that looks like:
lfence
jmpq *%r11
This ensures that if the value in register %r11 was loaded from memory, then
the value in %r11 is (architecturally) correct prior to the jump.
Also adds a new target feature to X86: +lvi-cfi
("cfi" meaning control-flow integrity)
The feature can be added via clang CLI using -mlvi-cfi.
This is an alternate implementation to https://reviews.llvm.org/D75934 That merges the thunk insertion functionality with the existing X86 retpoline code.
Differential Revision: https://reviews.llvm.org/D76812
|
|
|
|
|
|
|
|
| |
Retpoline
Introduce a ThunkInserter CRTP base class from which new thunk types can inherit, e.g., thunks to mitigate https://software.intel.com/security-software-guidance/software-guidance/load-value-injection.
Differential Revision: https://reviews.llvm.org/D76811
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Indirect Thunks"
There are applications for indirect call/branch thunks other than retpoline for Spectre v2, e.g.,
https://software.intel.com/security-software-guidance/software-guidance/load-value-injection
Therefore it makes sense to refactor X86RetpolineThunks as a more general capability.
Differential Revision: https://reviews.llvm.org/D76810
|
|
|
|
|
|
|
|
| |
RDF is designed to be target agnostic. Therefore it would be useful to have it available for other targets, such as X86.
Based on a previous patch by Krzysztof Parzyszek
Differential Revision: https://reviews.llvm.org/D75932
|
|
|
|
|
|
|
| |
D80647 did not fix https://bugs.llvm.org/show_bug.cgi?id=46076
This is the fix.
(cherry picked from commit b9c6871a9570975827dc0bbeb39131c99c8daf8e)
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://bugs.llvm.org/show_bug.cgi?id=46076
Reviewed By: nickdesaulniers, pcc
Differential Revision: https://reviews.llvm.org/D80647
(cherry picked from commit a2a3e9f0a6e91103a0d1fa73086dbdf109c48f69)
|
|
|
|
|
|
|
| |
PR45539:
https://bugs.llvm.org/show_bug.cgi?id=45539
(cherry picked from commit 01bcc3e9371470e1974f066ced353df15e10056d)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2019 v16.6
After updating MSVS19 from v16.4 to v16.6 I faced with a build errors compiling in Debug mode.
It complains on clang-tblgen.exe and llvm-tblgen.exe cmd line args.
VS compiler had a bug. It dynamically creates an object with constexpr ctor in Debug mode. This bug was fixed in VS2019 v16.5.
A workaround was implemented for that and everything works until v16.5 comes.
The workaround became irrelevant since v16.5 and caused build errors.
So I disabled the workaround for VS2019 v16.5 and higher.
This relates to http://llvm.org/PR41367.
Differential Revision: https://reviews.llvm.org/D80433
(cherry picked from commit 46e5c5fe778b92b2a7e2c2ad3610e1da6794bd5e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Patch in D78477 introduced a new test for gcov and this test is failing on arm:
- http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-full-sh/builds/4752/steps/ninja%20check%202/logs/stdio
- http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10501/steps/ninja%20check%202/logs/stdio
So try to fix it in reducing the number of threads.
Reviewers: marco-c
Reviewed By: marco-c
Subscribers: dberris, kristof.beyls, #sanitizers, serge-sans-paille, sylvestre.ledru
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D79621
(cherry picked from commit 0da37bedc2667da371eda30595a06210595881d0)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Part of the changes in D44564 made BasicAA not CFG only due to it using
PhiAnalysisValues which may have values invalidated.
Subsequent patches (rL340613) appear to have addressed this limitation.
BasicAA should not be invalidated by non-CFG-altering passes.
A concrete example is MemCpyOpt which preserves CFG, but we are testing
it invalidates BasicAA.
llvm-dev RFC: https://groups.google.com/forum/#!topic/llvm-dev/eSPXuWnNfzM
Reviewers: john.brawn, sebpop, hfinkel, brzycki
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74353
(cherry picked from commit 0cecafd647ccd9d0acc5968d4d6e80c1cbdee275)
|
|
|
|
|
|
|
|
|
|
| |
After pseudo-expansion, we may end up with ADDI (add immediate)
instructions where the operand is not an immediate but a relocation.
For such instructions, attempts to get the immediate result in
assertion failures for obvious reasons.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=45432
(cherry picked from commit a56d057dfe3127c111c3470606c04e96d35b1fa3)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In BPF Instruction Selection DAGToDAG transformation phase,
BPF backend had an optimization to turn load from readonly data
section to direct load of the values. This phase is implemented
before libbpf has readonly section support and before alu32
is supported.
This phase however may generate incorrect type when alu32 is
enabled. The following is an example,
-bash-4.4$ cat ~/tmp2/t.c
struct t {
unsigned char a;
unsigned char b;
unsigned char c;
};
extern void foo(void *);
int test() {
struct t v = {
.b = 2,
};
foo(&v);
return 0;
}
The compiler will turn local variable "v" into a readonly section.
During instruction selection phase, the compiler generates two
loads from readonly section, one 2 byte load or 1 byte load, e.g., for 2 loads,
t8: i32,ch = load<(dereferenceable load 2 from `i8* getelementptr inbounds
(%struct.t, %struct.t* @__const.test.v, i64 0, i32 0)`, align 1),
anyext from i16> t3, GlobalAddress:i64<%struct.t* @__const.test.v> 0, undef:i64
t9: ch = store<(store 2 into %ir.v1.sub1), trunc to i16> t3, t8,
FrameIndex:i64<0>, undef:i64
BPF backend changed t8 to i64 = Constant<2> and eventually the generated machine IR:
t10: i64 = MOV_ri TargetConstant:i64<2>
t40: i32 = SLL_ri_32 t10, TargetConstant:i32<8>
t41: i32 = OR_ri_32 t40, TargetConstant:i64<0>
t9: ch = STH32<Mem:(store 2 into %ir.v1.sub1)> t41, TargetFrameIndex:i64<0>,
TargetConstant:i64<0>, t3
Note that t10 in the above is not correct. The type should be i32 and instruction
should be MOV_ri_32. The reason for incorrect insn selection is BPF insn selection
generated an i64 constant instead of an i32 constant as specified in the original
load instruction. Such incorrect insn sequence eventually caused the following
fatal error when a COPY insn tries to copy a 64bit register to a 32bit subregister.
Impossible reg-to-reg copy
UNREACHABLE executed at ../lib/Target/BPF/BPFInstrInfo.cpp:42!
This patch fixed the issue by using the load result type instead of always i64
when doing readonly load optimization.
Differential Revision: https://reviews.llvm.org/D81630
(cherry picked from commit 4db1878158a3f481ff673fef2396c12b7a53d280)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no
longer embedded into binaries (mostly for --version output).
Without it, most binaries need to relink after every single
commit, even if they didn't change otherwise (due to, say,
a documentation-only commit).
LLVM_APPEND_VC_REV is ON by default, so this doesn't change the
default behavior of anything.
With this, all clients of GenerateVersionFromVCS.cmake honor
LLVM_APPEND_VC_REV.
Differential Revision: https://reviews.llvm.org/D72855
(cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes https://github.com/clangd/clangd/issues/256
Reviewers: kbobyrev
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73056
(cherry picked from commit fb3d9153c01b9a560680465190d6ecd804e4c486)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In BTF, pointee type pruning is used to reduce cluttering
too many unused types into prog BTF. For example,
struct task_struct {
...
struct mm_struct *mm;
...
}
If bpf program does not access members of "struct mm_struct",
there is no need to bring types for "struct mm_struct" to BTF.
This patch fixed a bug where an incorrect pruning happened.
The test case like below:
struct t;
typedef struct t _t;
struct s1 { _t *c; };
int test1(struct s1 *arg) { ... }
struct t { int a; int b; };
struct s2 { _t c; }
int test2(struct s2 *arg) { ... }
After processing test1(), among others, BPF backend generates BTF types for
"struct s1", "_t" and a placeholder for "struct t".
Note that "struct t" is not really generated. If later a direct access
to "struct t" member happened, "struct t" BTF type will be generated
properly.
During processing test2(), when processing member type "_t c",
BPF backend sees type "_t" already generated, so returned.
This caused the problem that "struct t" BTF type is never generated and
eventually causing incorrect type definition for "struct s2".
To fix the issue, during DebugInfo type traversal, even if a
typedef/const/volatile/restrict derived type has been recorded in BTF,
if it is not a type pruning candidate, type traversal of its base type continues.
Differential Revision: https://reviews.llvm.org/D82041
(cherry picked from commit 89648eb16d01725457f958e634d16c534b64c42c)
|
|
|
|
|
|
|
|
|
|
| |
As reported in PR45186, we could be in a situation where we don't
want to handle unaligned memory accesses for FP scalars but still
have VSX (which allows unaligned access for vectors). Change the
default to only apply to scalars.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=45186
(cherry picked from commit 099a875f28d0131a6ae85af91b9eb8627917fbbe)
|
|
|
|
|
|
|
|
|
|
|
|
| |
We relied on the fact that the iterators walks through the elements of a
DenseSet in a deterministic order (which is not true). This caused
ThinLTO cache misses. This patch addresses this problem.
See PR 45819 for additional information
https://bugs.llvm.org/show_bug.cgi?id=45819
Differential Revision: https://reviews.llvm.org/D79772
(cherry picked from commit 252892fea7088abbeff9476e0ecbacc091d135a0)
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently emit incorrect codegen for this constraint because we set it as a
constraint that allows registers. This will cause the value to be copied to the
stack and that address to be passed as the address. This is not what we want.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=42762
Differential revision: https://reviews.llvm.org/D77542
(cherry picked from commit aede24ecaa08db806fb173faf2de9cff95df8cee)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in https://bugs.llvm.org/show_bug.cgi?id=45709 we can hit an
infinite loop in legalization since we set the legalization action for
ISD::SELECT_CC for all fixed length vector types to Promote. Without some
different legalization action for the type being promoted to, the legalizer
simply loops. Since we don't have patterns to match the node, the right
legalization action should be Expand.
Differential revision: https://reviews.llvm.org/D79854
(cherry picked from commit 793cc518b9428a0b7a40c59d4ecd5939a7bc84f7)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix for PR39865 took care of some of the handling for half precision
but it missed a number of issues that still exist. This patch fixes the
remaining issues that cause crashes in the PPC back end.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=45776
Differential revision: https://reviews.llvm.org/D79283
(cherry picked from commit 1a493b0fa556a07c728862c3c3f70bfd8683bef0)
|
|
|
|
|
|
|
|
|
| |
This patch adds support for Vector Multiply-Sum Unsigned Doubleword Modulo
instruction; vmsumudm.
Differential Revision: https://reviews.llvm.org/D80294
(cherry picked from commit a28e9f1208608f8d18750bb88ca74722fb0bcce4)
|
|
|
|
|
|
|
|
|
| |
Due to libPolly now using the component infrastructure, it no longer carries all
dependencies as it used to do.
Differential Revision: https://reviews.llvm.org/D79295
(cherry picked from commit 8ceee08de135c4c96980bd750bb5e95348126980)
|
|
|
|
| |
(cherry picked from commit 37309fb02f60557f18971dc575904c0fc56c91ab)
|
|
|
|
|
|
|
|
|
| |
As a side effect, this tests (and fix a bug) in the compiler extension handling
of components.
Differential Revision: https://reviews.llvm.org/D78358
(cherry picked from commit e849e7a700907441ee82ace9d0a9555ae7eb9811)
|