Lines Matching +full:pull +full:- +full:requests
10 Tests for new optimizations or miscompilation fixes should be pre-committed.
15 This means that pull requests should generally contain two commits: First,
23 Exceptions: When fixing assertion failures or infinite loops, do not pre-commit
35 llvm/utils/update_test_checks.py --opt-binary build/bin/opt \
39 Exceptions: Hand-written CHECK lines are allowed for debuginfo tests.
50 optimize in some non-trivial way, you may add it as well -- however, the bulk
54 For example, a test checking multi-use behavior of a fold involving the
58 test all combinations of everything. If you have multi-use tests, and you have
59 commuted tests, you shouldn't also add commuted multi-use tests.
61 Prefer to keep bit-widths for tests low to improve performance of proof checking using alive2. Usin…
67 tests, such that **exactly one** different pre-condition of your transform is
70 ### Add multi-use tests
72 Add multi-use tests that ensures your transform does not increase instruction
87 Exceptions: For transform that only produce one instruction, multi-use tests
96 pre-commited tests. You should not see something like this:
99 ; CHECK-NEXT: [[OR:%.*]] = or i8 [[X]], [[Y]]
108 %y2 = mul i8 %y, %y ; thwart complexity-based canonicalization
140 Finally, you can have non-splat vectors, where the vector elements are not
151 Non-splat vectors will often not fold by default. You should **not** try to
157 If your transform involves instructions that can have poison-generating flags,
169 The same also applies to fast-math-flags (FMF). In that case, please always
175 The test categories mentioned above are non-exhaustive. There may be more tests
179 …* For folds involving memory accesses like load/store, check that scalable vectors and non-byte-si…
180 …* For folds that interact with the bitwidth in some non-trivial way, check an illegal type like i1…
185 Your pull request description should contain one or more
195 For example, here is a pair of proofs that both `(x-y)+y` and `(x+y)-y` can
264 Note that the `@llvm.assume` intrinsic is used to specify pre-conditions for
266 a pre-condition.
271 need to use non-constants in the proof.
273 ### Common pre-conditions
278 ; %x is non-negative:
279 %nonneg = icmp sgt i8 %x, -1
307 - remove extraneous instructions, if any
309 - reduce variable widths, for example to i16, i8, or i4
311 - add the --disable-undef-input command line flag, which
324 ; For 16-bit pointers
328 If reducing the bitwidth does not help, try `-disable-undef-input`. This will
333 Finally, it's possible to build alive2 locally and use `-smt-to=<m>` to verify
339 ### Real-world usefulness
342 only a tiny fraction of them are useful for real-world code.
344 Transforms that do not have real-world usefulness provide *negative* value to
346 complexity and increasing compile-time overhead.
348 We do not require explicit proof of real-world usefulness for every transform
349 -- in most cases the usefulness is fairly "obvious". However, the question may
353 In particular, fixes for fuzzer-generated missed optimization reports will
354 likely be rejected if there is no evidence of real-world usefulness.
362 …ng`: For analyzing instructions, e.g. for known bits, non-zero, etc. Tests should usually use `-pa…
366 * `VectorCombine`: For folds of vector operations that require target-dependent cost-modelling.
372 ### Canonicalization and target-independence
374 InstCombine is a target-independent canonicalization pass. This means that it
377 form needs to be the same for all targets, and not depend on target-specific
387 optimization purpose. For example, InstCombine will canonicalize non-strict
396 target-specific cost-modelling, **will not be accepted**. The only permitted
397 target-dependence is on DataLayout and TargetLibraryInfo.
399 The use of TargetTransformInfo is only allowed for hooks for target-specific
401 already inherently target-dependent anyway.
403 For vector-specific transforms that require cost-modelling, the VectorCombine
405 alternatives, target-dependent transforms may be accepted into
411 [PatternMatch.h](https://github.com/llvm/llvm-project/blame/main/llvm/include/llvm/IR/PatternMatch.…
416 // Fold (A - B) + B and B + (A - B) to A.
430 ConstantInt::get(A->getType(), *C1 + *C2));
442 * `m_ImmConstant(C)`: Match any non-constant-expression constant into
509 is usually not necessary, as side-effect free instructions without users
516 ### Multi-use handling
525 need to add a one-use check for the inner instruction.
527 One-use checks can be performed using the `m_OneUse()` matcher, or the
528 `V->hasOneUse()` method.
534 complexity to handle cases with no real-world relevance). The right level of
543 you should also handle the de-Morgan conjugate using `or`.
544 * Handle non-splat vector constants if doing so is free, but do not add
546 * Do not handle non-canonical patterns, unless there is a specific motivation
549 still occur in multi-use scenarios. This is fine to do if there is specific
550 real-world motivation, but you should not go out of your way to do this
553 properties, but the fold can be generalized to non-constant values by making
560 * Do not ask new contributors to implement non-splat vector support in code
561 reviews. If you think non-splat vector support for a fold is both
562 worthwhile and policy-compliant (that is, the handling would not result in
564 follow-up patch.