<div dir="ltr">reg_values is a pointer to a struct. This is more like disambiguating:<div><br></div><div>load of reg_values vs</div><div><br></div><div>store to reg_values->data.te[...]</div><div><br></div><div><br></div><div>TBAA should handle this case too.</div><div><br></div><div>David</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 21, 2015 at 3:55 PM, Pete Cooper <span dir="ltr"><<a href="mailto:peter_cooper@apple.com" target="_blank">peter_cooper@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From a quick look at the IR snippet you gave:<br>
<br>
%32 = load %struct.varray_head_tag*, %struct.varray_head_tag** @reg_values, align 8, !tbaa !2 ; <<<<< @reg_values<br>
%data.i = getelementptr inbounds %struct.varray_head_tag, %struct.varray_head_tag* %32, i64 0, i32 4 ; <<<<<<<<br>
%te.i = bitcast %union.varray_data_tag* %data.i to [1 x %struct.elt_list*]* ; <<<<<<<<<<<br>
%arrayidx.i = getelementptr inbounds [1 x %struct.elt_list*], [1 x %struct.elt_list*]* %te.i, i64 0, i64 %indvars.iv.i ; <<<<<<<<<<<<<br>
store %struct.elt_list* null, %struct.elt_list** %arrayidx.i, align 8, !tbaa !2<br>
<br>
no alias seems to be the right choice here, although its something I’d have expected BasicAA to work out.<br>
<br>
I think we’re ultimately looking to see if a field of @reg_values aliases @reg_values itself, which is of course not possible.<br>
<br>
So we have something along the lines of<br>
<br>
struct varray_head_tag {<br>
type0 field0;<br>
type1 field1;<br>
type2 field2;<br>
type3 field3;<br>
varray_data_tag field4[some number of elements]; // this is what %data.i points to, and %arrayidx.i points to a specific element<br>
} reg_values;<br>
<br>
so by storing in to field4[%indvars.iv.i], we can’t be aliasing @reg_values. Unless i’ve got my number of pointers wrong of course, then it might be possible.<br>
<span class="HOEnZb"><font color="#888888"><br>
Pete<br>
</font></span><div class="HOEnZb"><div class="h5">> On Jul 21, 2015, at 3:43 PM, Michael Zolotukhin <<a href="mailto:mzolotukhin@apple.com">mzolotukhin@apple.com</a>> wrote:<br>
><br>
><br>
>> On Jul 21, 2015, at 3:34 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
>><br>
>> Based on function names and structures, this is some version of GCC :)<br>
> Yep, it’s 403.gcc from SPEC2006 (I thought I mentioned it - but probably I only did that on IRC).<br>
><br>
>> Any way you can post the entire .ll file?<br>
> It’s an LTO build, so it’d be troublesome.. I tried to print the module in lldb, but after a several minutes it hasn’t even finished printing globals (which I assume is the very beginning).<br>
><br>
>><br>
>> Because it's globalsmodref, it's hard to debug without the other<br>
>> functions, since it goes over all the functions to determine address<br>
>> takenness, etc :)<br>
> Yep, I understand that - I’m still in debugger though, so if you’re interested in some particular data, I can try collecting it. I can try to dump the module too, but it might be not-practical in the end:)<br>
><br>
> Michael<br>
>><br>
>><br>
>> On Tue, Jul 21, 2015 at 3:23 PM, Michael Zolotukhin<br>
>> <<a href="mailto:mzolotukhin@apple.com">mzolotukhin@apple.com</a>> wrote:<br>
>>> Hi Chandler,<br>
>>><br>
>>> We observed some regressions in our regular testing (despite I saw nothing<br>
>>> suspicious in my runs). I did accurate investigation and was able to<br>
>>> reproduce and track down the regression.<br>
>>> I found the exact request to GlobalsModRef that results in the performance<br>
>>> loss (I added a limit on number of requests into the implementation and<br>
>>> bisected the number to find the interesting request).<br>
>>><br>
>>> Here are the details:<br>
>>><br>
>>> We’re checking following two locations:<br>
>>><br>
>>> (lldb) p ((llvm::Instruction*)(LocA.Ptr))->dump()<br>
>>> %arrayidx.i = getelementptr inbounds [1 x %struct.elt_list*], [1 x<br>
>>> %struct.elt_list*]* %te.i, i64 0, i64 %indvars.iv.i<br>
>>> (lldb) p ((llvm::Instruction*)(LocB.Ptr))->dump()<br>
>>> @reg_values = internal unnamed_addr global %struct.varray_head_tag* null,<br>
>>> align 8<br>
>>><br>
>>> and the function in question is “cselib_init”:<br>
>>> (lldb) p<br>
>>> ((llvm::Instruction*)(LocA.Ptr))->getParent()->getParent()->getName()<br>
>>> (llvm::StringRef) $3 = (Data = "cselib_init", Length = 11)<br>
>>><br>
>>> Corresponding underlying values:<br>
>>> (lldb) p UV2->dump()<br>
>>> @reg_values = internal unnamed_addr global %struct.varray_head_tag* null,<br>
>>> align 8<br>
>>> (lldb) p UV1->dump()<br>
>>> %32 = load %struct.varray_head_tag*, %struct.varray_head_tag** @reg_values,<br>
>>> align 8, !tbaa !2<br>
>>><br>
>>> Backtrace:<br>
>>> (lldb) bt<br>
>>> * thread #1: tid = 0x120baaf, 0x00000001038b752a libLTO.dylib`(anonymous<br>
>>> namespace)::GlobalsModRef::alias(this=0x000000010eba5c10,<br>
>>> LocA=0x00007fff5fbf4198, LocB=0x00007fff5fbf6268) + 570 at<br>
>>> GlobalsModRef.cpp:519, queue = 'com.apple.main-thread', stop reason = step<br>
>>> over<br>
>>> * frame #0: 0x00000001038b752a libLTO.dylib`(anonymous<br>
>>> namespace)::GlobalsModRef::alias(this=0x000000010eba5c10,<br>
>>> LocA=0x00007fff5fbf4198, LocB=0x00007fff5fbf6268) + 570 at<br>
>>> GlobalsModRef.cpp:519<br>
>>> frame #1: 0x00000001038b82f7 libLTO.dylib`non-virtual thunk to<br>
>>> (anonymous namespace)::GlobalsModRef::alias(this=0x000000010eba5c30,<br>
>>> LocA=0x00007fff5fbf4198, LocB=0x00007fff5fbf6268) + 55 at<br>
>>> GlobalsModRef.cpp:562<br>
>>> frame #2: 0x00000001038d6aa8<br>
>>> libLTO.dylib`llvm::AliasAnalysis::getModRefInfo(this=0x000000010eba5c30,<br>
>>> S=0x000000010a1a22e0, Loc=0x00007fff5fbf6268) + 120 at AliasAnalysis.cpp:288<br>
>>> frame #3: 0x0000000103a0a814<br>
>>> libLTO.dylib`llvm::MemoryDependenceAnalysis::getPointerDependencyFrom(this=0x000000010e6cf0c0,<br>
>>> MemLoc=0x00007fff5fbf6268, isLoad=true, ScanIt=llvm::BasicBlock::iterator at<br>
>>> 0x00007fff5fbf4390, BB=0x000000010a19ffa0, QueryInst=0x000000010a1a20c8) +<br>
>>> 1908 at MemoryDependenceAnalysis.cpp:570<br>
>>> frame #4: 0x0000000103a0ffa5<br>
>>> libLTO.dylib`llvm::MemoryDependenceAnalysis::GetNonLocalInfoForBlock(this=0x000000010e6cf0c0,<br>
>>> QueryInst=0x000000010a1a20c8, Loc=0x00007fff5fbf6268, isLoad=true,<br>
>>> BB=0x000000010a19ffa0, Cache=0x0000000100f9d568, NumSortedEntries=0) + 2165<br>
>>> at MemoryDependenceAnalysis.cpp:965<br>
>>> frame #5: 0x0000000103a0e3a9<br>
>>> libLTO.dylib`llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(this=0x000000010e6cf0c0,<br>
>>> QueryInst=0x000000010a1a20c8, Pointer=0x00007fff5fbf62a8,<br>
>>> Loc=0x00007fff5fbf6268, isLoad=true, StartBB=0x000000010a19ffa0,<br>
>>> Result=0x00007fff5fbf6bf0, Visited=0x00007fff5fbf6208, SkipFirstBlock=false)<br>
>>> + 5897 at MemoryDependenceAnalysis.cpp:1200<br>
>>> frame #6: 0x0000000103a0cb3b<br>
>>> libLTO.dylib`llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(this=0x000000010e6cf0c0,<br>
>>> QueryInst=0x000000010a1a20c8, Result=0x00007fff5fbf6bf0) + 635 at<br>
>>> MemoryDependenceAnalysis.cpp:911<br>
>>> frame #7: 0x000000010340c5b5 libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::processNonLocalLoad(this=0x000000010e6ce680,<br>
>>> LI=0x000000010a1a20c8) + 101 at GVN.cpp:1706<br>
>>> frame #8: 0x0000000103408eef libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::processLoad(this=0x000000010e6ce680, L=0x000000010a1a20c8)<br>
>>> + 1551 at GVN.cpp:1905<br>
>>> frame #9: 0x00000001034080fd libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::processInstruction(this=0x000000010e6ce680,<br>
>>> I=0x000000010a1a20c8) + 397 at GVN.cpp:2220<br>
>>> frame #10: 0x0000000103407d1b libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::processBlock(this=0x000000010e6ce680,<br>
>>> BB=0x000000010a19ffa0) + 251 at GVN.cpp:2394<br>
>>> frame #11: 0x0000000103401755 libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::iterateOnFunction(this=0x000000010e6ce680,<br>
>>> F=0x00000001085f69f8) + 1541 at GVN.cpp:2677<br>
>>> frame #12: 0x0000000103400fef libLTO.dylib`(anonymous<br>
>>> namespace)::GVN::runOnFunction(this=0x000000010e6ce680,<br>
>>> F=0x00000001085f69f8) + 623 at GVN.cpp:2352<br>
>>> frame #13: 0x00000001027cd05b<br>
>>> libLTO.dylib`llvm::FPPassManager::runOnFunction(this=0x000000010eba6810,<br>
>>> F=0x00000001085f69f8) + 427 at LegacyPassManager.cpp:1520<br>
>>> frame #14: 0x00000001027cd375<br>
>>> libLTO.dylib`llvm::FPPassManager::runOnModule(this=0x000000010eba6810,<br>
>>> M=0x000000010115c5f0) + 117 at LegacyPassManager.cpp:1540<br>
>>> frame #15: 0x00000001027cdda1 libLTO.dylib`(anonymous<br>
>>> namespace)::MPPassManager::runOnModule(this=0x000000010e6cbaf0,<br>
>>> M=0x000000010115c5f0) + 1409 at LegacyPassManager.cpp:1596<br>
>>> frame #16: 0x00000001027cd636<br>
>>> libLTO.dylib`llvm::legacy::PassManagerImpl::run(this=0x000000010e6cb740,<br>
>>> M=0x000000010115c5f0) + 310 at LegacyPassManager.cpp:1698<br>
>>> frame #17: 0x00000001027ce521<br>
>>> libLTO.dylib`llvm::legacy::PassManager::run(this=0x00007fff5fbf82b8,<br>
>>> M=0x000000010115c5f0) + 33 at LegacyPassManager.cpp:1729<br>
>>><br>
>>><br>
>>> The function body is in the attached file.<br>
>>><br>
>>><br>
>>><br>
>>> GlobalsModRef reports NoAlias for this pair, here:<br>
>>> if (GV1 || GV2) {<br>
>>> // If the global's address is taken, pretend we don't know it's a<br>
>>> pointer to<br>
>>> // the global.<br>
>>> if (GV1 && !NonAddressTakenGlobals.count(GV1))<br>
>>> GV1 = nullptr;<br>
>>> if (GV2 && !NonAddressTakenGlobals.count(GV2))<br>
>>> GV2 = nullptr;<br>
>>><br>
>>> // If the two pointers are derived from two different non-addr-taken<br>
>>> // globals, or if one is and the other isn't, we know these can't alias.<br>
>>> if ((GV1 || GV2) && GV1 != GV2)<br>
>>> return NoAlias;<br>
>>><br>
>>> // Otherwise if they are both derived from the same addr-taken global,<br>
>>> we<br>
>>> // can't know the two accesses don't overlap.<br>
>>> }<br>
>>><br>
>>><br>
>>> Thanks,<br>
>>> Michael<br>
>>><br>
>>> On Jul 17, 2015, at 12:18 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
>>><br>
>>> On Fri, Jul 17, 2015 at 9:13 AM Evgeny Astigeevich<br>
>>> <<a href="mailto:evgeny.astigeevich@arm.com">evgeny.astigeevich@arm.com</a>> wrote:<br>
>>>><br>
>>>> It’s Dhrystone.<br>
>>><br>
>>> Dhrystone has historically not been a good indicator of real-world<br>
>>> performance fluctuations, especially at this small of a shift.<br>
>>><br>
>>> I'd like to see if we see any fluctuation on larger and more realistic<br>
>>> application benchmarks. One advantage of the flag being set is that we<br>
>>> should get runs from folks who have automatic builds and runs periodically<br>
>>> from trunk. Those should help give an accurate picture.<br>
>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: Chandler Carruth [mailto:<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>]<br>
>>>> Sent: 17 July 2015 16:10<br>
>>>><br>
>>>><br>
>>>> To: Evgeny Astigeevich; Chandler Carruth<br>
>>>> Cc: LLVM Developers Mailing List<br>
>>>><br>
>>>> Subject: Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Can you say what Benchmark or give a test case so we understand the nature<br>
>>>> of the regression? As Gerolf said, that will be important to understand what<br>
>>>> is best to do.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Fri, Jul 17, 2015, 06:43 Evgeny Astigeevich<br>
>>>> <<a href="mailto:Evgeny.Astigeevich@arm.com">Evgeny.Astigeevich@arm.com</a>> wrote:<br>
>>>><br>
>>>> Yes, the regression is stable. I double checked this. A full benchmark run<br>
>>>> consists of at least 10 sub-runs to validate the score.<br>
>>>><br>
>>>> I also checked if there were regressions of this benchmark across<br>
>>>> different ARM hardware versions. I found all regressions of this benchmark<br>
>>>> were in range 1.6%-2%.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Kind regards,<br>
>>>><br>
>>>> Evgeny Astigeevich<br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: Chandler Carruth [mailto:<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>]<br>
>>>> Sent: 17 July 2015 07:52<br>
>>>> To: Evgeny Astigeevich; Chandler Carruth<br>
>>>> Cc: LLVM Developers Mailing List; Michael Zolotukhin<br>
>>>><br>
>>>><br>
>>>> Subject: Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Hey, thanks for benchmarking.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> How stable is the 2% regression?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Michael ran some benchmarks with GlobalsModRef completely disabled and the<br>
>>>> only differences were in the noise. This was a complete spec2k6 run along<br>
>>>> with some others. Based on the number of benchmarks run there, I'm going to<br>
>>>> go ahead and submit these patches, but if you can clarify the impact here,<br>
>>>> we can look at potentially some other tradeoff. I'm not particularly set on<br>
>>>> one set of defaults, etc, I just don't want to keep patches held up based on<br>
>>>> that. We can flip the default back and forth as new data arrives.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Thu, Jul 16, 2015 at 12:23 PM Evgeny Astigeevich<br>
>>>> <<a href="mailto:evgeny.astigeevich@arm.com">evgeny.astigeevich@arm.com</a>> wrote:<br>
>>>><br>
>>>> Hi Chandler,<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I ran couple benchmarks with LTO turned on and your patches on ARM<br>
>>>> hardware.<br>
>>>><br>
>>>> There were no performance degradation of one benchmark and 2% slowdown of<br>
>>>> another benchmark.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Kind regards,<br>
>>>><br>
>>>> Evgeny Astigeevich<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On<br>
>>>> Behalf Of Evgeny Astigeevich<br>
>>>> Sent: 15 July 2015 15:12<br>
>>>><br>
>>>><br>
>>>> To: 'Chandler Carruth'; Gerolf Hoflehner<br>
>>>> Cc: LLVM Developers Mailing List<br>
>>>> Subject: Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Hi Chandler,<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I would like to run some benchmarks on ARM hardware and to look at impact<br>
>>>> of your patches on LTO.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Kind regards,<br>
>>>><br>
>>>> Evgeny Astigeevich<br>
>>>><br>
>>>><br>
>>>><br>
>>>> From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On<br>
>>>> Behalf Of Chandler Carruth<br>
>>>><br>
>>>><br>
>>>> Sent: 15 July 2015 10:45<br>
>>>> To: Chandler Carruth; Gerolf Hoflehner<br>
>>>> Cc: LLVM Developers Mailing List<br>
>>>> Subject: Re: [LLVMdev] GlobalsModRef (and thus LTO) is completely broken<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I've fixed the obvious bugs I spotted in r242281. These should be pure<br>
>>>> correctness improvements.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I've sent the two patches I'm imagining to address the core issue here:<br>
>>>><br>
>>>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11213&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=afUkV0gvA0SLeyMv6xJJL0ehANc4_rY-eQWWRApxga0&s=1MuHie_gyMTquazGVgYdkn6nTYPDFZhvFqkL4aFw9LE&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11213</a><br>
>>>><br>
>>>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11214&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=afUkV0gvA0SLeyMv6xJJL0ehANc4_rY-eQWWRApxga0&s=U8bTI0hMbTBXMuLNjIHcg4lkln01PoXppaN8uMbEmwY&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11214</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Currently, I have the unsafe alias results disabled by default, but with a<br>
>>>> flag that can re-enable them if needed. I don't feel really strongly about<br>
>>>> which way the default is set -- but that may be because I don't have lots of<br>
>>>> users relying on LTO. I'll let others indicate which way they would be most<br>
>>>> comfortable.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Some IRC conversations indicated that early benchmark results with GMR<br>
>>>> completely disabled weren't showing really significant swings, so maybe this<br>
>>>> relatively small reduction in power of GMR won't be too problematic for<br>
>>>> folks. Either way, I'm open to the different approaches. It's D11214 that I<br>
>>>> care a lot about. =]<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Thanks for all the thoughts here!<br>
>>>><br>
>>>> -Chandler<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Jul 14, 2015 at 11:25 PM Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>> Replying here, but several of the questions raised boil down to "couldn't<br>
>>>> you make the usage of GetUnderlyingObject conservatively correct?". I'll try<br>
>>>> and address that.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I think this *is* the right approach, but I think it is very hard to do<br>
>>>> without effectively disabling this part of GlobalsModRef. That is, the easy<br>
>>>> ways are likely to fire very frequently IMO.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> The core idea is to detect a "no information" state coming out of<br>
>>>> GetUnderlyingObject (likely be providing a custom version just for<br>
>>>> GlobalsModRef and tailored to its use cases). This is particularly effective<br>
>>>> at avoiding the problems with the recursion limit. But let's look at what<br>
>>>> cases we *wouldn't* return that. Here are the cases I see when I thought<br>
>>>> about this last night with Hal, roughly in descending likelihood I would<br>
>>>> guess:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 1) We detect some global or an alloca. In that case, even BasicAA would be<br>
>>>> sufficient to provide no-alias. GMR shouldn't be relevant.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 2) We detect a phi, select, or inttoptr, and stop there.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 3) We detect a load and stop there.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 4) We detect a return from a function.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> 5) We detect an argument to the function.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I strongly suspect the vast majority of queries hit #1. That's why BasicAA<br>
>>>> is *so* effective. Both #4 and #5 I think are actually reasonable places for<br>
>>>> GMR to potentially say "no-alias" and provide useful definitive information.<br>
>>>> But I also suspect these are the least common.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So let's look at #2 and #3 because I think they're interesting. For these,<br>
>>>> I think it is extremely hard to return "no-alias". It seems extremely easy<br>
>>>> for a reasonable and innocuous change to the IR to introduce a phi or a<br>
>>>> select into one side of the GetUnderlyingObject but not the other. If that<br>
>>>> ever happens, we can't return "no-alias" for #2, or we need to add really<br>
>>>> expensive updates. It also seems reasonable (if not as likely) to want<br>
>>>> adding a store and load to the IR to not trigger a miscompile. If it is<br>
>>>> possible for a valid optimization pass to do reg2mem on an SSA value, then<br>
>>>> that could happen to only one side of the paired GetUnderlyingObject and<br>
>>>> break GMR with #3. If that seems like an unreasonable thing to do, consider<br>
>>>> loop re-rolling or other transformations which may need to take things in<br>
>>>> SSA form at move them out of SSA form. Even if we then try immediately to<br>
>>>> put it back *into* SSA form, before we do that we create a point where GMR<br>
>>>> cannot correctly return no-alias.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> So ultimately, I don't think we want to rely on GMR returning "no-alias"<br>
>>>> for either #2 or #3 because of the challenge of actually updating it in all<br>
>>>> of the circumstances that could break them. That means that *only* #4 and #5<br>
>>>> are going to return "no-alias" usefully. And even then, function inlining<br>
>>>> and function outlining both break #4 and #5, so you have to preclude those<br>
>>>> transforms while GMR is active. And I have serious doubts about these<br>
>>>> providing enough value to be worth the cost.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> I think the better way to approach this is the other way around. Rather<br>
>>>> than doing a backwards analysis to see if one location reaches and global<br>
>>>> and the other location doesn't reach a global, I think it would be much more<br>
>>>> effective to re-cast this as a forward analysis that determines all the<br>
>>>> memory locations in a function that come from outside the function, and use<br>
>>>> that to drive the no-alias responses.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Jul 14, 2015 at 12:12 PM Gerolf Hoflehner <<a href="mailto:ghoflehner@apple.com">ghoflehner@apple.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>> I wouldn’t be willing to give up performance for hypothetical issues.<br>
>>>> Please protect all your changes with options. For some of your concerns it<br>
>>>> is probably hard to provide a test case that shows an/the actual issue.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I certainly agree that it will be very hard to provide a test case and<br>
>>>> extremely rare to see this in the wild for most of these issues. As long as<br>
>>>> I can remove the problematic update API we currently have (which as its an<br>
>>>> API change can't really be put behind flags), I'm happy to have flags<br>
>>>> control whether or not GMR uses the unsound / stale information to try to<br>
>>>> answer alias queries. Do you have any opinion about what the default value<br>
>>>> of the flags should be?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> I'll go ahead and prepare the patches, as it seems like we're all ending<br>
>>>> up in the same position, and just wondering about the precise tradeoffs we<br>
>>>> want to settle on.<br>
>>>><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> LLVM Developers mailing list<br>
>>>><br>
>>>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>><br>
>>>><br>
>>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>><br>
>>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>><br>
>>><br>
>>><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>>><br>
><br>
><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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
<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" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>