Changes in debug-info-blocks.ll

89baeaef - Reapply "RegAllocFast: Rewrite and improve"

Tue, 22 Sep 2020 12:55:54 +0000

Reapply "RegAllocFast: Rewrite and improve"This reverts commit 73a6a164b84a8195defbb8f5eeb6faecfc478ad4. List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

73a6a164 - Revert "Reapply Revert "RegAllocFast: Rewrite and improve""

Tue, 22 Sep 2020 09:20:10 +0000

Revert "Reapply Revert "RegAllocFast: Rewrite and improve""This reverts commit 55f9f87da2c2ad791b9e62cccb1c035e037444fa.Breaks following buildbots:http://lab.llvm.org:8011/builders/lldb-arm-ubuntu/builds/4306http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9154 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

55f9f87d - Reapply Revert "RegAllocFast: Rewrite and improve"

Mon, 21 Sep 2020 12:45:06 +0000

Reapply Revert "RegAllocFast: Rewrite and improve"This reverts commit dbd53a1f0c939a55e7719c39d08179468f9ad3dc.Needed lldb test updates List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

dbd53a1f - Temporarily Revert "RegAllocFast: Rewrite and improve"

Sat, 19 Sep 2020 01:00:02 +0000

Temporarily Revert "RegAllocFast: Rewrite and improve"as it's breaking a few tests in the lldb test suite.Bot: http://lab.llvm.org:8011/builders/lldb-arm-ubuntu/builds/4226/steps/test/logs/stdioThis reverts commit c8757ff3aa7dd7a25a6343f6ef74a70c7be04325. List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

c8757ff3 - RegAllocFast: Rewrite and improve

Mon, 14 Sep 2020 16:48:12 +0000

RegAllocFast: Rewrite and improveThis rewrites big parts of the fast register allocator. The basicstrategy of doing block-local allocation hasn't changed but I tweakedseveral details:Track register state on register units instead of physicalregisters. This simplifies and speeds up handling of register aliases.Process basic blocks in reverse order: Definitions are known to endregister livetimes when walking backwards (contrary when walkingforward then uses may or may not be a kill so we need heuristics).Check register mask operands (calls) instead of conservativelyassuming everything is clobbered. Enhance heuristics to detectkilling uses: In case of a small number of defs/uses check if they areall in the same basic block and if so the last one is a killing use.Enhance heuristic for copy-coalescing through hinting: We check thefirst k defs of a register for COPYs rather than relying on there justbeing a single definition. When testing this on the full llvmtest-suite including SPEC externals I measured:average 5.1% reduction in code size for X86, 4.9% reduction in code onaarch64. (ranging between 0% and 20% depending on the test) 0.5%faster compiletime (some analysis suggests the pass is slightly slowerthan before, but we more than make up for it because later passes arefaster with the reduced instruction count)Also adds a few testcases that were broken without this patch, inparticular bug 47278.Patch mostly by Matthias Braun List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

0779dffb - Remove the obsolete BlockByRefStruct flag from LLVM IR

Wed, 18 Sep 2019 22:38:56 +0000

Remove the obsolete BlockByRefStruct flag from LLVM IRDIFlagBlockByRefStruct is an unused DIFlag that originally was used byclang to express (Objective-)C block captures in debug info. For thelast year Clang has been emitting complex DIExpressions to describeblock captures instead, which makes all the code supporting this flagredundant.This patch removes the flag and all supporting "dead" code, so we canreuse the bit for something else in the future.Since this only affects debug info generated by Clang with the blockextension this mostly affects Apple platforms and I don't have anybitcode compatibility concerns for removing this. The Verifier willreject debug info that uses the bit and thus degrade gracefully whenLTO'ing older bitcode with a newer compiler.rdar://problem/44304813Differential Revision: https://reviews.llvm.org/D67453llvm-svn: 372272 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

ca0e4b36 - [DebugInfo] LiveDebugValues: correctly discriminate kinds of variable locations

Thu, 29 Aug 2019 11:20:54 +0000

[DebugInfo] LiveDebugValues: correctly discriminate kinds of variable locationsThe missing line added by this patch ensures that only spilt variablelocations are candidates for being restored from the stack. Otherwise,register or constant-value information can be interpreted as a spilllocation, through a union.The added regression test replicates a scenario where this occurs: thestack load from [rsp] causes the register-location DBG_VALUE to be"restored" to rsi, when it should be left alone. See PR43058 for details.Un x-fail a test that was suffering from this from a previous patch.Differential Revision: https://reviews.llvm.org/D66895llvm-svn: 370334 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

313d2ce9 - [DebugInfo] LiveDebugValues should always revisit backedges if it skips them

Thu, 29 Aug 2019 10:53:29 +0000

[DebugInfo] LiveDebugValues should always revisit backedges if it skips themThe "join" method in LiveDebugValues does not attempt to join unseenpredecessor blocks if their out-locations aren't yet initialized, insteadthe block should be re-visited later to see if any locations have changedvalidity. However, because the set of blocks were all being "process"'donce before "join" saw them, that logic in "join" was actually ignoringlegitimate out-locations on the first pass through. This meant that someinvalidated locations were not removed from the head of loops, allowingillegal locations to persist.Fix this by removing the run of "process" before the main join/process loopin ExtendRanges. Now the unseen predecessors that "join" skips truly areuninitialized, and we come back to the block at a later time to re-run"join", see the @baz function added.This also fixes another fault where stack/register transfers in the entryblock (or any other before-any-loop-block) had their tranfers initiallyignored, and were then never revisited. The MIR test added tests for thisbehaviour.XFail a test that exposes another bug; a fix for this is coming in D66895.Differential Revision: https://reviews.llvm.org/D66663llvm-svn: 370328 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.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/CodeGen/ARM/debug-info-blocks.ll

6f24c877 - [DebugInfo] Unify dumping of address ranges

Tue, 16 Jan 2018 11:17:57 +0000

[DebugInfo] Unify dumping of address rangesSummary:This patch unifies the printing of address ranges as [0x0, 0x1).rdar://34822059Reviewers: aprantl, dblaikieSubscribers: mehdi_amini, llvm-commitsDifferential Revision: https://reviews.llvm.org/D42056llvm-svn: 322543 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

16aa4cf7 - llvm-dwarfdump: Make -brief the default and add a -verbose option instead.

Mon, 11 Sep 2017 23:05:20 +0000

llvm-dwarfdump: Make -brief the default and add a -verbose option instead.Differential Revision: https://reviews.llvm.org/D37717llvm-svn: 312972 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

a058736c - [dwarfdump] Pretty print location expressions and location lists

Tue, 29 Aug 2017 21:41:21 +0000

[dwarfdump] Pretty print location expressions and location listsSummary:Based on Fred's patch here: https://reviews.llvm.org/D6771I can't seem to commandeer the old review, so I'm creating a new one.With that change the locations exrpessions are pretty printed inline in theDIE tree. The output looks like this for debug_loc entries: DW_AT_location [DW_FORM_data4] (0x00000000 0x0000000000000001 - 0x000000000000000b: DW_OP_consts +3 0x000000000000000b - 0x0000000000000012: DW_OP_consts +7 0x0000000000000012 - 0x000000000000001b: DW_OP_reg0 RAX, DW_OP_piece 0x4 0x000000000000001b - 0x0000000000000024: DW_OP_breg5 RDI+0)And like this for debug_loc.dwo entries: DW_AT_location [DW_FORM_sec_offset] (0x00000000 Addr idx 2 (w/ length 190): DW_OP_consts +0, DW_OP_stack_value Addr idx 3 (w/ length 23): DW_OP_reg0 RAX, DW_OP_piece 0x4)Simple locations without ranges are printed inline: DW_AT_location [DW_FORM_block1] (DW_OP_reg4 RSI, DW_OP_piece 0x4, DW_OP_bit_piece 0x20 0x0)The debug_loc(.dwo) dumping in changed accordingly to factor the code.Reviewers: dblaikie, aprantl, frissSubscribers: mgorny, javed.absar, hiraditya, llvm-commits, JDevlieghereDifferential Revision: https://reviews.llvm.org/D37123llvm-svn: 312042 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

abe04759 - Remove the obsolete offset parameter from @llvm.dbg.value

Fri, 28 Jul 2017 20:21:02 +0000

Remove the obsolete offset parameter from @llvm.dbg.valueThere is no situation where this rarely-used argument cannot besubstituted with a DIExpression and removing it allows us to simplifythe DWARF backend. Note that this patch does not yet remove any ofthe newly dead code.rdar://problem/33580047Differential Revision: https://reviews.llvm.org/D35951llvm-svn: 309426 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

ffc498df - Align definition of DW_OP_plus with DWARF spec [3/3]

Wed, 14 Jun 2017 13:14:38 +0000

Align definition of DW_OP_plus with DWARF spec [3/3]Summary:This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things. The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack. This is done in three stages:• The first patch (LLVM) adds support for DW_OP_plus_uconst.• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.Patch by Sander de Smalen.Reviewers: echristo, pcc, aprantlReviewed By: aprantlSubscribers: fhahn, javed.absar, aprantl, llvm-commitsDifferential Revision: https://reviews.llvm.org/D33894llvm-svn: 305386 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

75819aed - [PR27284] Reverse the ownership between DICompileUnit and DISubprogram.

Fri, 15 Apr 2016 15:57:41 +0000

[PR27284] Reverse the ownership between DICompileUnit and DISubprogram.Currently each Function points to a DISubprogram and DISubprogram has ascope field. For member functions the scope is a DICompositeType. DIScopespoint to the DICompileUnit to facilitate type uniquing.Distinct DISubprograms (with isDefinition: true) are not part of the typehierarchy and cannot be uniqued. This change removes the subprogramslist from DICompileUnit and instead adds a pointer to the owning compileunit to distinct DISubprograms. This would make it easy for ThinLTO tostrip unneeded DISubprograms and their transitively referenced debug info.Motivation----------Materializing DISubprograms is currently the most expensive operation whendoing a ThinLTO build of clang.We want the DISubprogram to be stored in a separate Bitcode block (or thesame block as the function body) so we can avoid having to expensivelydeserialize all DISubprograms together with the global metadata. If afunction has been inlined into another subprogram we need to store areference the block containing the inlined subprogram.Attached to https://llvm.org/bugs/show_bug.cgi?id=27284 is a python scriptthat updates LLVM IR testcases to the new format.http://reviews.llvm.org/D19034llvm-svn: 266446 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

b8089516 - testcase gardening: update the emissionKind enum to the new syntax. (NFC)

Fri, 01 Apr 2016 00:16:49 +0000

testcase gardening: update the emissionKind enum to the new syntax. (NFC)llvm-svn: 265081 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

f7346e0a - Hopefully fix debug-info-blocks.ll test on win32 bot

Sat, 19 Dec 2015 03:32:23 +0000

Hopefully fix debug-info-blocks.ll test on win32 botllc_dwarf adds an mtriple, which forces this to use COFF, causingthe test to fail. Hopefully using regular llc without the triplewill work fine everywherellvm-svn: 256084 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.ll

00cbf9a6 - Clean up the processing of dbg.value in various places

Sat, 19 Dec 2015 02:02:44 +0000

Clean up the processing of dbg.value in various placesSummary:First up is instcombine, where in the dbg.declare -> dbg.value conversion,the llvm.dbg.value needs to be called on the actual loaded value, ratherthan the address (since the whole point of this transformation is to beable to get rid of the alloca). Further, now that that's cleaned up, wecan remove a hack in the backend, that would add an implicit OP_deref ifthe argument to dbg.value was an alloca. This stems from before theexistence of DIExpression and is no longer necessary since the deref canbe expressed explicitly.Now, in order to make sure that the tests pass with this change, we need tocorrect the printing of DEBUG_VALUE comments to take into account theexpression, which wasn't taken into account before.Unfortunately, for both these changes, there were a number of incorrecttest cases (mostly the wrong number of DW_OP_derefs, but also a couplewhere the test itself was broken more badly). aprantl and I have gonethrough and adjusted these test case in order to make them pass withthese fixes and in some cases to make sure they're actually testingwhat they are meant to test.Reviewers: aprantlSubscribers: dsandersDifferential Revision: http://reviews.llvm.org/D14186llvm-svn: 256077 List of files: /llvm-project-15.0.7/llvm/test/CodeGen/ARM/debug-info-blocks.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/CodeGen/ARM/debug-info-blocks.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/CodeGen/ARM/debug-info-blocks.ll