<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 21, 2013, at 10:37 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 21, 2013, at 4:47 PM, Evan Cheng <<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On Nov 20, 2013, at 10:38 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br><br><blockquote type="cite">----- Original Message -----<br><blockquote type="cite">From: "Evan Cheng" <<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>><br>To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>Cc: "LLVM" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>>, "Junbum Lim" <<a href="mailto:junbums@gmail.com">junbums@gmail.com</a>><br>Sent: Wednesday, November 20, 2013 7:48:13 PM<br>Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare<br><br><br>On Nov 20, 2013, at 5:38 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br><br><blockquote type="cite">----- Original Message -----<br><blockquote type="cite">From: "Evan Cheng" <<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>><br>To: "Junbum Lim" <<a href="mailto:junbums@gmail.com">junbums@gmail.com</a>><br>Cc: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>Sent: Wednesday, November 20, 2013 7:01:49 PM<br>Subject: Re: [LLVMdev] sinking address computing in<br>CodeGenPrepare<br><br><br>On Nov 20, 2013, at 3:10 PM, Junbum Lim <<a href="mailto:junbums@gmail.com">junbums@gmail.com</a>> wrote:<br><br><blockquote type="cite"><br><br>When multiple GEPs or other operations are used for the address<br>calculation, OptimizeMemoryInst() performs address matching and<br>determines a final addressing expression as a simple form (e.g.,<br>ptrtoint/add/inttoptr) and sinks it into user's block so that<br>ISel<br>could have better chance to fold address computation into LDRs<br>and<br>STRs. However, OptimizeMemoryInst() seems to do this<br>transformation even when the address calculation derived from a<br>single GEP, resulting in poor alias analysis because GEP is no<br>longer used.<br></blockquote><br>I don't follow your last statement. How does this impact AA?<br>CodeGenPrep is run late, after AA is done.<br></blockquote><br>I don't know if this is relevant for Lim or not, but some targets<br>use AA during CodeGen (instruction scheduling mostly, but SDAG<br>too).<br></blockquote><br>MachineSched uses AA to determine if something is loop invariant,<br>which basically boils down to looking at machine operand and see<br>it's pointing to constant memory. I don't see how that's impact by<br>GEP vs. ADDS + MUL.<br></blockquote><br>MachineSched can use AA for a lot more than that. I use AA during scheduling because, in addition to picking up loads from constant memory, it lets me do a kind of modulo scheduling for unrolled loops. AA can tell that loads and stores to different arrays don't alias, and loads and stores to different offsets of the same array don't alias.<br></blockquote><br>I still don't understand what this has to do with whether GEP is lowered in codegenprep though.<br><br><blockquote type="cite"><br><blockquote type="cite">Also, the analysis should have already been done<br>and cached.<br></blockquote><br>BasicAA has a cache internally, but as far as I can tell, only to guard against recursion (and it is emptied after each query). Am I missing something?<br></blockquote><br>It's not clear to me how AA is used in codegen. I understand some information are transferred to memoperands during LLVM IR to SDISel conversion. Is AA actually being recomputed using LLVM IR during codegen?<br></div></blockquote><div><br></div><div>In general, when AA is used during codegen, it grabs the IR value from the machine memoperands, then runs normal IR-level alias analysis. The IR needs to stay around and be immutable. That’s why anything that changes aliasing of IR-level memory ops should be run before CodeGen. For example, stack coloring needs to conservatively mutilate the machine memoperands to work around this problem.</div><div><br></div><div>We need to sink address computation to expose addressing modes to ISEL, but I’m not sure why we need to lower to ptrtoint. That doesn’t seem good for AA at all.</div><br><div>-Andy</div><div><br></div></div></div></blockquote><div><br></div><div><br></div><div><div style="margin: 0px; font-size: 13px; font-family: Courier; "><div style="margin: 0px; ">When multiple GEPs or other multiple operations are used for the address calculation, codegenprep performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block, resulting in folding of address computations into LDRs and STRs.</div><div style="margin: 0px; min-height: 16px; "><br></div><div style="margin: 0px; ">However, codegenprep performs this conversion even for an address expression from a single GEP, resulting in poor AA in scheduler because basicaa doesn't handle IntToPrt. As a simple workaround, I think the GEP could be directly sunk without breaking it into integers operations if the address is simply derived from a single GEP. </div><div style="margin: 0px; "><br></div><div style="margin: 0px; ">-Jun</div></div></div><div><br></div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite"><br>-Hal<br><br><blockquote type="cite"><br>Evan<br><br><blockquote type="cite"><br>-Hal<br><br><blockquote type="cite"><br>Evan<br><br><blockquote type="cite"><br>So, do you think it is a possible workaround to sink a GEP<br>without<br>converting it into a set of integer operations<br>(ptrtoint/add/inttoptr) if the address mode is derived only from<br>a<br>single GEP.<br><br>Thanks,<br>Jun<br><br><br>On Nov 12, 2013, at 7:14 PM, Evan Cheng <<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>><br>wrote:<br><br><blockquote type="cite"><br>On Nov 12, 2013, at 11:24 AM, Junbum Lim <<a href="mailto:junbums@gmail.com">junbums@gmail.com</a>><br>wrote:<br><br><blockquote type="cite"><br>I wonder why CodeGenPrepare breaks GEP into integer<br>calculations<br>(ptrtoin/add/inttopt) instead of directly sinking the address<br>calculation using GEP into user's block.<br></blockquote><br>I believe it's primary for address mode matching where only part<br>of the GEP can be folded (depending on the instruction set).<br><br>Evan<br><br><blockquote type="cite"><br>Thanks,<br>Jun<br><br><br>On Nov 12, 2013, at 12:07 PM, Evan Cheng <<a href="mailto:evan.cheng@apple.com">evan.cheng@apple.com</a>><br>wrote:<br><br><blockquote type="cite">The reason for this is to allow folding of address computation<br>into loads and stores. A lot of modern arch, e.g. X86 and arm,<br>have complex addressing mode.<br><br>Evan<br><br>Sent from my iPad<br><br><blockquote type="cite">On Nov 12, 2013, at 8:39 AM, Junbum Lim <<a href="mailto:junbums@gmail.com">junbums@gmail.com</a>><br>wrote:<br><br>Hi All,<br><br>In CodeGenPrepare pass, OptimizeMemoryInst() try to sink<br>address computing into users' block by converting GET to<br>integers? It appear that it have impacts on ISel's result,<br>but<br>I'm not clear about the main purpose of the transformation.<br><br>FROM :<br>for.body.lr.ph:<br> %zzz = getelementptr inbounds %struct.SS* %a2, i32<br> 0, i32 35<br><br>for.body:<br> %4 = load double* %zzz, align 8, !tbaa !0<br><br>TO :<br>for.body:<br>%sunkaddr27 = ptrtoint %struct.SS* %a2 to i32 <-----<br>sink<br>address computing into user's block<br>%sunkaddr28 = add i32 %sunkaddr27, 272<br>%sunkaddr29 = inttoptr i32 %sunkaddr28 to double*<br>%4 = load double* %sunkaddr29, align 8, !tbaa !8<br><br><br>From what I observed, this transformation can cause poor<br>alias<br>analysis results without using GEP. So, I want to see there<br>is any way to avoid this conversion.<br><br>My question is :<br>1. Why do we need to sink address computing into users'<br>block?<br>What is the benefit of this conversion ?<br>2. Can we directly use GEP instead of breaking it into<br>integer<br>calculations ?<br><br>Thanks,<br>Jun<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></blockquote><br></blockquote><br></blockquote><br></blockquote><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br><br></blockquote><br>--<br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<br></blockquote><br><br></blockquote><br>--<span class="Apple-converted-space"> </span><br>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory</blockquote></div></blockquote></div><br></div></blockquote></div><br></body></html>