similar to: Need help with changes to 'ScheduleDAGInstrs' on the v3.8 branch

On Apr 26, 2013, at 3:53 AM, Martin J. O'Riordan <Martin.ORiordan at movidius.com> wrote: > I am migrating the llvm/clang derived compiler for our processor from the > v3.1 to v3.2 codebase. This has mostly gone well except that instruction > latency scheduling is no longer happening. > > The people who implemented this previously sub-classed 'ScheduleDAGInstrs'

Hi All, I've encountered an issue where tail merging MIs is causing a problem with the post-RA MI scheduler dependency analysis and I'm not sure of the best way to address the problem. In my case, the branch folding pass (lib/CodeGen/BranchFolding.cpp) is merging common code from BB#14 and BB#15 into BB#16. It's clear that there are 4 common instructions (marked with an *) in BB#14

Hello all. I'm investigating a problem with "Machine Instruction Scheduling" that is rooted in incorrect alias information. Things go wrong in the "Merge disjoint stack slots"[1] pass when a store instruction fails to get updated after its stack slot is merged. As a result, when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store and a

Running an Ubuntu Raring VM which was built a week ago that is now running 3.8-rc6, I was booting it last night when it hung. After a few forced reboots, it came back up and I found the attached in kern.log. Mostly, the VM has been used for testing anisble deployment, so not a lot of work, just upgrading and installing software, then rebooting. Are these reports useful? Is there any

Hi all, I have a question regarding the latency of the true dependency of a store followed by an aliased load in ScheduleDAGInstrs. The latency seems to depend on the store and load being volatile or not as can be seen in the post-RA-sched debug output of the attached ARM example: $ llc -O3 -debug-only=post-RA-sched store_load_latency_test.ll ... SU(2): STRi12 %R2<kill>,

Hello, The ScheduleDAGInstrs::buildSchedGraph() function creates def/uses lists by iterating over all instruction operands and calls addPhysRegDeps() if used post-RA (line ~770 ff.). If an operand is a def, the uses of that registers are cleared (ScheduleDAGInstrs.cpp:333: Uses.eraseAll(Reg); ). As a consequence, if an instruction has an explicit use of a register and an implicit def of the

Hi, Can anyone help me to understand the ScheduleDAGInstrs::buildSchedGraph() method? I find the handling of AliasChain is disturbing since: 1. A new alias chain add deps to all possibly aliasing SUs, and then clears those lists. 2. When AliasChain is present, the addChainDependency() method is called, but the target hook areMemAccessesTriviallyDisjoint() called inside

Hi, I write again regarding buildSchedGraph(), as I am still not happy about things there. I have found at least two examples which do not work out: 1) SU(2) Store "Value A" SU(1) Store "Value A" SU(0) Load "Value A" If MIsNeedChainEdge() returns false for SU(0) and SU(1), SU(0) is inserted into RejectedMemNodes and removed from its MemUses SU list, as this

Hi Tom, Thanks a lot for your explanations, now it makes a lot more sense ;) I had a slightly closer look at the R600 packetizer, and the issue is that the third LSHL instruction has both an implicit use and *afterwards* an implicit def of T1_XYZW. The latter def causes the current ScheduleDAGInstrs implementation to ignore the implicit use, thus the ScheduleDAG only contains an

Hello again, Sorry -- I think I found the problem somewhere else. I was a bit confused and missed the fact that adjustChainDeps() is called a few lines down and does just what I wanted :-) I would like to instead ask another question: Why is I->isCtrl() used in code like // Iterate over chain dependencies only. for (SUnit::const_succ_iterator I = SUb->Succs.begin(), E =

Hi, Thank you for the reply. >It looks to me like we can choose any subset of edges here and be correct. We're basically trying to prune/pinch the DAG edges here. They can easily blow up with AA sched. I would guess that isCtrl() edges are good ones to bypass because they could be a low-latecy edges, whereas true data dependencies from a load are expected to be >higher latency, so they

Hi, I'm trying to use the VLIWPacketizerList to schedule instructions for the R600 target, and I'm running into this assertion failure: ScheduleDAGInstrs.cpp:558: Cannot schedule terminators or labels! I think I might not be using the VLIWPacketizerList class correctly. I've attached my code to this email. Can anyone spot what I'm doing wrong? Also, I had to add a LiveIntervals

> On Mar 5, 2018, at 6:14 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Mar 5, 2018, at 3:38 PM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> When Ahmed and I worked on the decompiler, we first targeted MC. Going to MI was more difficult and really wouldn’t have gotten us a

HiHo Hans, sorry, but I cannot see any tarballs shipped in [2]? Forgot to upload? Would like to give this pre-release a try on my Ubuntu/precise AMD64 system. Thanks in advance. Regards, - Sedat - [1] http://lists.llvm.org/pipermail/llvm-dev/2016-February/094797.html [2] http://llvm.org/pre-releases/3.8.0/rc2/

On Fri, Feb 5, 2016 at 8:43 AM, Hans Wennborg <hans at chromium.org> wrote: > On Fri, Feb 5, 2016 at 12:48 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >> sorry, but I cannot see any tarballs shipped in [2]? >> Forgot to upload? >> >> Would like to give this pre-release a try on my Ubuntu/precise AMD64 system. > > They're not ready yet. It

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "James Molloy" <James.Molloy at arm.com>, "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" > <aschwaighofer at apple.com>, "LLVM Dev" <llvm-dev at

Our processor also has some issues regarding the handling of denormals - scalar and vector - and we ran into a related problem only a few days ago. The v3.8 compiler has done a lot of good work on optimisations for floating-point math, but ironically one of them broke our implementation of 'nextafterf'. The desired code fragment (FP32) is: float xAbs = fabsf(x); since we know our

Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,

On Sat, Feb 6, 2016 at 12:34 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Sat, Feb 6, 2016 at 1:55 AM, Hans Wennborg <hans at chromium.org> wrote: >> On Fri, Feb 5, 2016 at 8:43 AM, Hans Wennborg <hans at chromium.org> wrote: >>> On Fri, Feb 5, 2016 at 12:48 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: >>>> sorry, but I cannot

Hi Tom, I followed a bit the mailing-list but still see no LLVM v3.7.1 tarballs. Can you pleas take care of this? In case of that i386 breakage do a new v3.7.2 release, please. Not sure if this has impact on x86_64 (AMD64)? Thanks. Regards, - Sedat - [1] https://llvm.org/bugs/show_bug.cgi?id=25920