| /llvm-project-15.0.7/clang/test/SemaCXX/ |
| H A D | crashes.cpp | 171 static int nsCSSRect::* sides; variable
176 int& x = dimenX.*sides; in ParseBoxCornerRadii()
|
| /llvm-project-15.0.7/llvm/test/YAMLParser/ |
| H A D | construct-seq.test | 5 - Mercury # Rotates - no light/dark sides.
|
| /llvm-project-15.0.7/llvm/test/Instrumentation/DataFlowSanitizer/ |
| H A D | union.ll | 24 ; In this case, we compute the unions on both sides because neither block
|
| /llvm-project-15.0.7/libcxx/docs/DesignDocs/ |
| H A D | UnspecifiedBehaviorRandomization.rst | 83 * ``std::nth_element``, there is no guarantee on the order from both sides of the
|
| /llvm-project-15.0.7/llvm/test/Transforms/InstCombine/ |
| H A D | icmp-ule-of-shl-1-by-bits-and-val-to-icmp-ne-of-lshr-val-by-bits-and-0.ll | 71 ; What if we have the same pattern on both sides?
|
| H A D | icmp-ugt-of-shl-1-by-bits-and-val-to-icmp-eq-of-lshr-val-by-bits-and-0.ll | 71 ; What if we have the same pattern on both sides?
|
| H A D | icmp-ult-of-not-of-shl-allones-by-bits-and-val-to-icmp-ne-of-lshr-val-by-bits-and-0.ll | 99 ; What if we have the same pattern on both sides?
|
| H A D | icmp-uge-of-not-of-shl-allones-by-bits-and-val-to-icmp-eq-of-lshr-val-by-bits-and-0.ll | 99 ; What if we have the same pattern on both sides?
|
| H A D | icmp-uge-of-add-of-shl-one-by-bits-to-allones-and-val-to-icmp-eq-of-lshr-val-by-bits-and-0.ll | 123 ; What if we have the same pattern on both sides?
|
| H A D | icmp-ult-of-add-of-shl-one-by-bits-to-allones-and-val-to-icmp-ne-of-lshr-val-by-bits-and-0.ll | 123 ; What if we have the same pattern on both sides?
|
| H A D | icmp-range.ll | 282 ; match and fold even if both sides are zexts (from different source types)
512 ; match and fold even if both sides are sexts (from different source types)
|
| H A D | onehot_merge.ll | 527 ; Shift-of-signbit replaced with 'icmp s*' for both sides
|
| /llvm-project-15.0.7/llvm/test/Transforms/LoopVectorize/AArch64/ |
| H A D | backedge-overflow.ll | 5 ; icmp with one of the sides being a loop varying non-AddRec expression.
|
| /llvm-project-15.0.7/llvm/test/Transforms/InstCombine/ARM/ |
| H A D | mve-v2i2v.ll | 335 ; opposite sides of the xor.
|
| /llvm-project-15.0.7/llvm/docs/ |
| H A D | HowToUpdateDebugInfo.rst | 94 * Merging identical loads/stores which occur on both sides of a CFG diamond
|
| H A D | AliasAnalysis.rst | 33 interface, use it, and to test both sides. It also explains some of the finer
|
| /llvm-project-15.0.7/llvm/test/CodeGen/X86/ |
| H A D | vselect.ll | 559 ; late shuffle magic, both sides of the blend are the same
|
| H A D | sad.ll | 1043 …ld tag the joining add as a vector reduction. We neeed to recognize that both sides can use psadbw.
1105 …ld tag the joining add as a vector reduction. We neeed to recognize that both sides can use psadbw.
|
| H A D | switch.ll | 2012 ; would have on the right. Case 60 would have the same rank on both sides, so is
|
| /llvm-project-15.0.7/llvm/test/Transforms/CorrelatedValuePropagation/ |
| H A D | overflow_predicate.ll | 332 ; Signed mul is constrained from both sides.
|
| /llvm-project-15.0.7/polly/lib/External/isl/imath/ |
| H A D | ChangeLog | 56 to missing type-casts on the right-hand sides of assignments.
|
| /llvm-project-15.0.7/llvm/lib/Target/X86/ |
| H A D | README.txt | 77 commutative, it is not matched with the load on both sides. The dag combiner
|
| /llvm-project-15.0.7/clang/docs/analyzer/ |
| H A D | checkers.rst | 1669 int b = a | 4 | a; // warn: identical expr on both sides
|
| /llvm-project-15.0.7/llvm/docs/TableGen/ |
| H A D | ProgRef.rst | 1863 The ``strings`` field expression uses ``suffix`` on both sides of the paste
|
| /llvm-project-15.0.7/lldb/docs/ |
| H A D | lldb-gdb-remote.txt | 11 registers a thread might have. Again with GDB, both sides pre-agree on how the
|