Home
last modified time | relevance | path

Searched refs:GEPs (Results 1 – 25 of 74) sorted by relevance

123

/llvm-project-15.0.7/llvm/test/Transforms/SeparateConstOffsetFromGEP/RISCV/
H A Dsplit-gep.ll9 ; Simple case when GEPs should be optimized.
36 ; Optimize GEPs when there sext instructions are needed to cast index value to expected type.
101 ; Optimized GEPs for multidimensional array with same base
132 ; Don't optimize GEPs for multidimensional array with same base because RISC-V doesn't support the …
166 ; No need to optimize GEPs, because there is critical amount with non-constant offsets.
192 ; No need to optimize GEPs, because the base variable is different.
227 ; No need to optimize GEPs, because the base of GEP instructions is different.
260 ; No need to optimize GEPs of multidimensional array, because the base of GEP instructions is diffe…
/llvm-project-15.0.7/llvm/test/Transforms/LoopStrengthReduce/
H A D2011-10-06-ReusePhi.ll4 ; Verify that scaled GEPs are not reused. rdar://5064068
17 ; GEPs are ugly
/llvm-project-15.0.7/llvm/test/Transforms/MergeFunc/
H A Dvector-GEP-crash.ll2 ; This used to cause a crash when compairing the GEPs
/llvm-project-15.0.7/llvm/test/Analysis/CostModel/X86/
H A Dgep.ll38 ; Check that we handle outlandishly large GEPs properly. This is unlikely to
39 ; be a valid pointer, but LLVM still generates GEPs like this sometimes in
/llvm-project-15.0.7/llvm/test/CodeGen/Hexagon/
H A Dcommon-gep-inbounds.ll4 ; We should generate new GEPs with "inbounds" flag.
H A Dglobal-const-gep.ll3 ; Test that global constant GEPs are calculated correctly
H A Dcommon-gep-basic.ll4 ; The mpyis from the two GEPs should be commoned out.
/llvm-project-15.0.7/llvm/test/Transforms/LoadStoreVectorizer/X86/
H A Dcodegenprepare-produced-address-math.ll31 ; If and only if the loads are in a different BB from the GEPs codegenprepare
32 ; would try to turn the GEPs into math, which makes LoadStoreVectorizer's job
/llvm-project-15.0.7/llvm/test/Transforms/InstCombine/
H A D2011-05-13-InBoundsGEP.ll4 ; must not discard GEPs that might overflow at runtime (aren't inbounds)
H A Dgepphigep.ll80 ; Check that instcombine doesn't insert GEPs before landingpad.
144 ; Check that instcombine doesn't fold GEPs into themselves through a loop
196 ; Instcombine shouldn't add new PHI nodes while folding GEPs if that will leave
/llvm-project-15.0.7/llvm/test/Transforms/InstSimplify/ConstProp/
H A Dgep-alias.ll2 ; Test that we don't replace an alias with its aliasee when simplifying GEPs.
/llvm-project-15.0.7/llvm/test/Analysis/BasicAA/
H A Dconstant-over-index.ll10 ; for GEPs to ignore TBAA.
/llvm-project-15.0.7/llvm/test/Transforms/Scalarizer/
H A Dvector-gep.ll3 ; Check that the scalarizer can handle vector GEPs with scalar indices
58 ; Check that the scalarizer can handle vector GEPs with scalar pointer
/llvm-project-15.0.7/llvm/test/CodeGen/Generic/
H A DbadFoldGEP.ll7 ;; The code is legal but not type-safe and the two GEPs should not be folded.
H A D2003-05-30-BadFoldGEP.ll7 ;; Error: A sequence of GEPs is folded incorrectly by llc during selection
/llvm-project-15.0.7/llvm/test/Transforms/SLPVectorizer/X86/
H A Dgep_mismatch.ll4 ; This code has GEPs with different index types, which should not
/llvm-project-15.0.7/llvm/docs/
H A DGetElementPtr.rst154 0`` index is needed. However, a closer inspection of how globals and GEPs work
254 What effect do address spaces have on GEPs?
299 How does VLA addressing work with GEPs?
302 GEPs don't natively support VLAs. LLVM's type system is entirely static, and GEP
362 Can I compare two values computed with GEPs?
434 As such, there are some ramifications of this for inbounds GEPs: scales implied
438 itself is logically treated as an unsigned value. This means that GEPs have an
488 reduces the range of possibilities for cases where two GEPs are effectively the
494 Some LLVM optimizers operate on GEPs by internally lowering them into more
/llvm-project-15.0.7/llvm/test/Assembler/
H A Dgetelementptr.ll11 ; Verify that constant expression GEPs work with i84 indices.
53 ; Verify that constant expression vector GEPs work.
/llvm-project-15.0.7/llvm/test/CodeGen/ARM/
H A Dfast-isel-remat-same-constant.ll7 ; generated by the GEPs. The first add generated killed the vreg for the #6680 constant which shou…
/llvm-project-15.0.7/llvm/test/CodeGen/PowerPC/
H A Dppc64-gep-opt.ll8 ; into GEPs with a single index, otherwise it will lower it into a
13 ; Check that when two complex GEPs are used in two basic blocks, LLVM can
/llvm-project-15.0.7/llvm/test/CodeGen/X86/
H A Drelptr-rodata.ll31 ; Ensure that inbound GEPs with constant offsets are also resolved.
/llvm-project-15.0.7/llvm/include/llvm/Transforms/Vectorize/
H A DSLPVectorizer.h144 GEPListMap GEPs; member
/llvm-project-15.0.7/llvm/test/CodeGen/RISCV/
H A Dsplit-offsets.ll54 ; Ditto. Check it when the GEPs are not in the entry block.
121 ; GEPs have been manually split so the base GEP does not get used by any memory
/llvm-project-15.0.7/llvm/test/Transforms/ConstraintElimination/
H A Dgeps-inbounds-precondition.ll4 ; Tests for using inbounds information from GEPs.
86 ; Same as inbounds_poison_is_ub2, but with individual GEPs in the %then and
166 ; Same as @inbounds_poison_does_not_cause_ub, but with separate GEPs in the
236 ; Tests for multiple inbound GEPs, make sure the largest upper bound is used.
/llvm-project-15.0.7/llvm/test/Analysis/LoopAccessAnalysis/
H A Dwrapping-pointer-versioning.ll14 ; Analyzing the IR does not help us because the GEPs are not
19 ; to check that the pointers don't wrap since the GEPs are not
83 ; to check that the pointers don't wrap since the GEPs are not

123