Changes in simple32.ll

615efc3e - [AlignmentFromAssumptions] Migrate tests to opaque pointers (NFC)

Wed, 22 Jun 2022 11:02:18 +0000

[AlignmentFromAssumptions] Migrate tests to opaque pointers (NFC)Tests were updated with (without manual fixup):https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

3f8027fb - [test] Update some test cases to use -passes when specifying the pipeline

Mon, 13 Sep 2021 08:43:38 +0000

[test] Update some test cases to use -passes when specifying the pipelineThis updates transform test cases for ADCE AddDiscriminators AggressiveInstCombine AlignmentFromAssumptions ArgumentPromotion BDCE CalledValuePropagation DCE Reg2Mem WholeProgramDevirtto use the -passes syntax when specifying the pipeline.Given that LLVM_ENABLE_NEW_PASS_MANAGER isn't set to off (which isa deprecated feature) the updated test cases already used the newpass manager, but they were using the legacy syntax when specifyingthe passes to run. This patch can be seen as a step toward deprecatingthat interface.This patch also removes some redundant RUN lines. Here I amreferring to test cases that had multiple RUN lines verifying boththe legacy "-passname" syntax and the new "-passes=passname" syntax.Since we switched the default pass manager to "new PM" both RUN lineshave verified the new PM version of the pass (more or less wastingtime running the same test twice), unless LLVM_ENABLE_NEW_PASS_MANAGERis set to "off". It is assumed that it is enough to run these testswith the new pass manager now.Differential Revision: https://reviews.llvm.org/D108472 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

c6647693 - [AssumeBundles] offset should be added to correctly calculate align

Fri, 02 Apr 2021 02:53:45 +0000

[AssumeBundles] offset should be added to correctly calculate alignThis is a patch to fix the bug in alignment calculation (see https://reviews.llvm.org/D90529#2619492).Consider this code:```call void @llvm.assume(i1 true) ["align"(i32* %a, i32 32, i32 28)]%arrayidx = getelementptr inbounds i32, i32* %a, i64 -1; aligment of %arrayidx?```The llvm.assume guarantees that `%a - 28` is 32-bytes aligned, meaning that `%a` is 32k + 28 for some k.Therefore `a - 4` cannot be 32-bytes aligned but the existing code was calculating the pointer as 32-bytes aligned.The reason why this happened is as follows.`DiffSCEV` stores `%arrayidx - %a` which is -4.`OffSCEV` stores the offset value of “align”, which is 28.`DiffSCEV` + `OffSCEV` = 24 should be used for `a - 4`'s offset from 32k, but `DiffSCEV` - `OffSCEV` = 32 was being used instead.Reviewed By: TykerDifferential Revision: https://reviews.llvm.org/D98759 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

78de7297 - Reland [AssumeBundles] Use operand bundles to encode alignment assumptions

Sat, 12 Sep 2020 11:36:45 +0000

Reland [AssumeBundles] Use operand bundles to encode alignment assumptionsNOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.htmlComplemantary to the assumption outliner prototype in D71692, this patchshows how we could simplify the code emitted for an alignemntassumption. The generated code is smaller, less fragile, and it makes iteasier to recognize the additional use as a "assumption use".As mentioned in D71692 and on the mailing list, we could adopt thisscheme, and similar schemes for other patterns, without adopting theassumption outlining. List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

7bfaa400 - Temporarily Revert "[AssumeBundles] Use operand bundles to encode alignment assumptions"

Thu, 16 Jul 2020 18:40:43 +0000

Temporarily Revert "[AssumeBundles] Use operand bundles to encode alignment assumptions"due to the performance bugs filed in https://bugs.llvm.org/show_bug.cgi?id=46753.An SROA change soon may obviate some of these problems.This reverts commit 8d09f20798ac180b1749276bff364682ce0196ab. List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

8d09f207 - [AssumeBundles] Use operand bundles to encode alignment assumptions

Mon, 13 Jul 2020 22:52:37 +0000

[AssumeBundles] Use operand bundles to encode alignment assumptionsSummary:NOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.htmlComplemantary to the assumption outliner prototype in D71692, this patchshows how we could simplify the code emitted for an alignemntassumption. The generated code is smaller, less fragile, and it makes iteasier to recognize the additional use as a "assumption use".As mentioned in D71692 and on the mailing list, we could adopt thisscheme, and similar schemes for other patterns, without adopting theassumption outlining.Reviewers: hfinkel, xbolva00, lebedev.ri, nikic, rjmccall, spatel, jdoerfert, sstefan1Reviewed By: jdoerfertSubscribers: thopre, yamauchi, kuter, fhahn, merge_guards_bot, hiraditya, bollu, rkruppe, cfe-commits, llvm-commitsTags: #clang, #llvmDifferential Revision: https://reviews.llvm.org/D71739 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

7ea46aee - Revert "[AssumeBundles] Use operand bundles to encode alignment assumptions"

Sat, 04 Jul 2020 19:45:41 +0000

Revert "[AssumeBundles] Use operand bundles to encode alignment assumptions"Assume bundle can have more than one entry with the same name,but at least AlignmentFromAssumptionsPass::extractAlignmentInfo() usesgetOperandBundle("align"), which internally assumes that it isn't thecase, and happily crashes otherwise.Minimal reduced reproducer: run `opt -alignment-from-assumptions` ontarget datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"target triple = "x86_64-unknown-linux-gnu"%0 = type { i64, %1*, i8*, i64, %2, i32, %3*, i8* }%1 = type opaque%2 = type { i8, i8, i16 }%3 = type { i32, i32, i32, i32 }; Function Attrs: nounwinddefine i32 @f(%0* noalias nocapture readonly %arg, %0* noalias %arg1) local_unnamed_addr #0 {bb: call void @llvm.assume(i1 true) [ "align"(%0* %arg, i64 8), "align"(%0* %arg1, i64 8) ] ret i32 0}; Function Attrs: nounwind willreturndeclare void @llvm.assume(i1) #1attributes #0 = { nounwind "reciprocal-estimates"="none" }attributes #1 = { nounwind willreturn }This is what we'd have with -mllvm -enable-knowledge-retentionThis reverts commit c95ffadb2474a4d8c4f598d94d35a9f31d9606cb. List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

c95ffadb - [AssumeBundles] Use operand bundles to encode alignment assumptions

Wed, 24 Jun 2020 11:18:21 +0000

[AssumeBundles] Use operand bundles to encode alignment assumptionsSummary:NOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.htmlComplemantary to the assumption outliner prototype in D71692, this patchshows how we could simplify the code emitted for an alignemntassumption. The generated code is smaller, less fragile, and it makes iteasier to recognize the additional use as a "assumption use".As mentioned in D71692 and on the mailing list, we could adopt thisscheme, and similar schemes for other patterns, without adopting theassumption outlining.Reviewers: hfinkel, xbolva00, lebedev.ri, nikic, rjmccall, spatel, jdoerfert, sstefan1Reviewed By: jdoerfertSubscribers: yamauchi, kuter, fhahn, merge_guards_bot, hiraditya, bollu, rkruppe, cfe-commits, llvm-commitsTags: #clang, #llvmDifferential Revision: https://reviews.llvm.org/D71739 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

8938a6c9 - [NFC] update test to make diff of the following commit clear

Fri, 19 Jun 2020 13:45:27 +0000

[NFC] update test to make diff of the following commit clear List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

cee313d2 - Revert "Temporarily Revert "Add basic loop fusion pass.""

Wed, 17 Apr 2019 04:52:47 +0000

Revert "Temporarily Revert "Add basic loop fusion pass.""The reversion apparently deleted the test/Transforms directory.Will be re-reverting again.llvm-svn: 358552 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

20c9207b - [AlignmentFromAssumptions] Set source and dest alignments of memory intrinsiscs separately

Thu, 22 Feb 2018 18:55:59 +0000

[AlignmentFromAssumptions] Set source and dest alignments of memory intrinsiscs separatelySummary:This change is part of step five in the series of changes to remove alignment argument frommemcpy/memmove/memset in favour of alignment attributes. In particular, this changes theAlignmentFromAssumptions pass to cease using the old getAlignment()/setAlignment API ofMemoryIntrinsic in favour of getting/setting source & dest specific alignments throughthe new API. This allows us to simplify some of the code in this pass and also be moreaggressive about setting the source and destination alignments separately.Steps:Step 1) Remove alignment parameter and create alignment parameter attributes formemcpy/memmove/memset. ( rL322965, rC322964, rL322963 )Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differingsource and dest alignments. ( rL323597 )Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774,rL324781, rL324784, rL324955, rL324960 )Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and theMemIntrinsicInst::[get|set]Alignment() methods.Reference http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.htmlReviewers: hfinkel, bollu, reamesReviewed By: reamesSubscribers: reames, llvm-commitsDifferential Revision: https://reviews.llvm.org/D43081llvm-svn: 325816 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

1e68724d - Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)

Fri, 19 Jan 2018 17:13:12 +0000

Remove alignment argument from memcpy/memmove/memset in favour of alignment attributes (Step 1)Summary: This is a resurrection of work first proposed and discussed in Aug 2015: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.htmland initially landed (but then backed out) in Nov 2015: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html The @llvm.memcpy/memmove/memset intrinsics currently have an explicit argumentwhich is required to be a constant integer. It represents the alignment of thedest (and source), and so must be the minimum of the actual alignment of thetwo. This change is the first in a series that allows source and dest to eachhave their own alignments by using the alignment attribute on their arguments. In this change we:1) Remove the alignment argument.2) Add alignment attributes to the source & dest arguments. We, temporarily, require that the alignments for source & dest be equal. For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 100, i32 4, i1 false)will now read call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 4 %dest, i8* align 4 %src, i32 100, i1 false) Downstream users may have to update their lit tests that check for@llvm.memcpy/memmove/memset call/declaration patterns. The following extended sed scriptmay help with updating the majority of your tests, but it does not catch all possiblepatterns so some manual checking and updating will be required.s~declare void @llvm\.mem(set|cpy|move)\.p([^(]*)$(.*), i32, i1$~declare void @llvm.mem\1.p\2(\3, i1)~gs~call void @llvm\.memset\.p([^(]*)i8$i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.memset.p\1i8(i8\2* \3, i8 \4, i8 \5, i1 \6)~gs~call void @llvm\.memset\.p([^(]*)i16$i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.memset.p\1i16(i8\2* \3, i8 \4, i16 \5, i1 \6)~gs~call void @llvm\.memset\.p([^(]*)i32$i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.memset.p\1i32(i8\2* \3, i8 \4, i32 \5, i1 \6)~gs~call void @llvm\.memset\.p([^(]*)i64$i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.memset.p\1i64(i8\2* \3, i8 \4, i64 \5, i1 \6)~gs~call void @llvm\.memset\.p([^(]*)i128$i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.memset.p\1i128(i8\2* \3, i8 \4, i128 \5, i1 \6)~gs~call void @llvm\.memset\.p([^(]*)i8$i8([^*]*)\* (.*), i8 (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.memset.p\1i8(i8\2* align \6 \3, i8 \4, i8 \5, i1 \7)~gs~call void @llvm\.memset\.p([^(]*)i16$i8([^*]*)\* (.*), i8 (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.memset.p\1i16(i8\2* align \6 \3, i8 \4, i16 \5, i1 \7)~gs~call void @llvm\.memset\.p([^(]*)i32$i8([^*]*)\* (.*), i8 (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.memset.p\1i32(i8\2* align \6 \3, i8 \4, i32 \5, i1 \7)~gs~call void @llvm\.memset\.p([^(]*)i64$i8([^*]*)\* (.*), i8 (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.memset.p\1i64(i8\2* align \6 \3, i8 \4, i64 \5, i1 \7)~gs~call void @llvm\.memset\.p([^(]*)i128$i8([^*]*)\* (.*), i8 (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.memset.p\1i128(i8\2* align \6 \3, i8 \4, i128 \5, i1 \7)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i8$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.mem\1.p\2i8(i8\3* \4, i8\5* \6, i8 \7, i1 \8)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i16$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.mem\1.p\2i16(i8\3* \4, i8\5* \6, i16 \7, i1 \8)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i32$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.mem\1.p\2i32(i8\3* \4, i8\5* \6, i32 \7, i1 \8)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i64$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.mem\1.p\2i64(i8\3* \4, i8\5* \6, i64 \7, i1 \8)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i128$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 [01], i1 ([^)]*)$~call void @llvm.mem\1.p\2i128(i8\3* \4, i8\5* \6, i128 \7, i1 \8)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i8$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i8 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.mem\1.p\2i8(i8\3* align \8 \4, i8\5* align \8 \6, i8 \7, i1 \9)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i16$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i16 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.mem\1.p\2i16(i8\3* align \8 \4, i8\5* align \8 \6, i16 \7, i1 \9)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i32$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i32 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.mem\1.p\2i32(i8\3* align \8 \4, i8\5* align \8 \6, i32 \7, i1 \9)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i64$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i64 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.mem\1.p\2i64(i8\3* align \8 \4, i8\5* align \8 \6, i64 \7, i1 \9)~gs~call void @llvm\.mem(cpy|move)\.p([^(]*)i128$i8([^*]*)\* (.*), i8([^*]*)\* (.*), i128 (.*), i32 ([0-9]*), i1 ([^)]*)$~call void @llvm.mem\1.p\2i128(i8\3* align \8 \4, i8\5* align \8 \6, i128 \7, i1 \9)~g The remaining changes in the series will:Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments.Step 3) Update Clang to use the new IRBuilder API.Step 4) Update Polly to use the new IRBuilder API.Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment() and getSourceAlignment() instead.Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the MemIntrinsicInst::[get|set]Alignment() methods.Reviewers: pete, hfinkel, lhames, reames, bolluReviewed By: reamesSubscribers: niosHD, reames, jholewinski, qcolombet, jfb, sanjoy, arsenm, dschuff, dylanmckay, mehdi_amini, sdardis, nemanjai, david2050, nhaehnle, javed.absar, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, llvm-commitsDifferential Revision: https://reviews.llvm.org/D41675llvm-svn: 322965 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

a4c2d150 - [PM] Port AlignmentFromAssumptions to the new PM.

Wed, 15 Jun 2016 06:18:01 +0000

[PM] Port AlignmentFromAssumptions to the new PM.This uses the "runImpl" pattern to share code between the old and new PM.llvm-svn: 272757 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

67cf9a72 - Revert "Change memcpy/memset/memmove to have dest and source alignments."

Thu, 19 Nov 2015 05:56:52 +0000

Revert "Change memcpy/memset/memmove to have dest and source alignments."This reverts commit r253511.This likely broke the bots inhttp://lab.llvm.org:8011/builders/clang-ppc64-elf-linux2/builds/20202http://bb.pgr.jp/builders/clang-3stage-i686-linux/builds/3787llvm-svn: 253543 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

72bc23ef - Change memcpy/memset/memmove to have dest and source alignments.

Wed, 18 Nov 2015 22:17:24 +0000

Change memcpy/memset/memmove to have dest and source alignments.Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.htmlThese intrinsics currently have an explicit alignment argument which isrequired to be a constant integer. It represents the alignment of thesource and dest, and so must be the minimum of those.This change allows source and dest to each have their own alignmentsby using the alignment attribute on their arguments. The alignmentargument itself is removed.There are a few places in the code for which the code needs to bechecked by an expert as to whether using only src/dest alignment issafe. For those places, they currently take the minimum of src/destalignments which matches the current behaviour.For example, code which used to read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false)will now read: call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false)For out of tree owners, I was able to strip alignment from calls using sed by replacing: (call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\)with: $1i1 false)and similarly for memmove and memcpy.I then added back in alignment to test cases which needed it.A similar commit will be made to clang which actually has many differences in alignment as nowIRBuilder can generate different source/dest alignments on calls.In IRBuilder itself, a new argument was added. Instead of calling: CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false)you now call CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false)There is a temporary class (IntegerAlignment) which takes the source alignment and rejectsimplicit conversion from bool. This is to prevent isVolatile here from passing its defaultparameter to the source alignment.Note, changes in future can now be made to codegen. I didn't change anything here, but thischange should enable better memcpy code sequences.Reviewed by Hal Finkel.llvm-svn: 253511 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

a79ac14f - [opaque pointer type] Add textual IR support for explicit type parameter to load instruction

Fri, 27 Feb 2015 21:17:42 +0000

[opaque pointer type] Add textual IR support for explicit type parameter to load instructionEssentially the same as the GEP change in r230786.A similar migration script can be used to update test cases, though a few moretest case improvements/changes were required this time around: (r229269-r229278)import fileinputimport sysimport repat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace$\d+$ *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)")for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line))Reviewers: rafael, dexonsmith, grosserDifferential Revision: http://reviews.llvm.org/D7649llvm-svn: 230794 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

79e6c749 - [opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction

Fri, 27 Feb 2015 19:29:02 +0000

[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instructionOne of several parallel first steps to remove the target type of pointers,replacing them with a single opaque pointer type.This adds an explicit type parameter to the gep instruction so that when thefirst parameter becomes an opaque pointer type, the type to gep through isstill available to the instructions.* This doesn't modify gep operators, only instructions (operators will be handled separately)* Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes.* geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float.* address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %xImportantly, the massive amount of test case churn has been automated bysame crappy python code. I had to manually update a few test cases thatwouldn't fit the script's model (r228970,r229196,r229197,r229198). Thepython script just massages stdin and writes the result to stdout, Ithen wrapped that in a shell script to handle replacing files, thenusing the usual find+xargs to migrate all the files.update.py:import fileinputimport sysimport reibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace$\d$) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace$\d$) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))")def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return linefor line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line)apply.sh:for name in "$@"do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp"doneThe actual commands:From llvm/src:find test/ -name *.ll | xargs ./apply.shFrom llvm/src/tools/clang:find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}"From llvm/src/tools/polly:find test/ -name *.ll | xargs ./apply.shAfter that, check-all (with llvm, clang, clang-tools-extra, lld,compiler-rt, and polly all checked out).The extra 'rm' in the apply.sh script is due to a few files in clang's testsuite using interesting unicode stuff that my python script was throwingexceptions on. None of those files needed to be migrated, so it seemedsufficient to ignore those cases.Reviewers: rafael, dexonsmith, grosserDifferential Revision: http://reviews.llvm.org/D7636llvm-svn: 230786 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll

f83e1f7f - [AlignmentFromAssumptions] Don't crash just because the target is 32-bit

Thu, 11 Sep 2014 08:40:17 +0000

[AlignmentFromAssumptions] Don't crash just because the target is 32-bitWe used to crash processing any relevant @llvm.assume on a 32-bit target(because we'd ask SE to subtract expressions of differing types). I've copiedour 'simple.ll' test, but with the data layout from arm-linux-gnueabihf to getsome meaningful test coverage here.llvm-svn: 217574 List of files: /llvm-project-15.0.7/llvm/test/Transforms/AlignmentFromAssumptions/simple32.ll