similar to: [LLVMdev] Undef registers in dependency graph

Greetings, I'm investigating a bug in the PowerPC back end in which a load from a storage address is being reordered prior to a store to the same storage address. I'm quite new to LLVM, so I would appreciate some help understanding what I'm seeing from the dumps. I assume that some information is missing that would represent the memory dependency, but I don't know what form that

Here's another data point that may be useful. [Scheduling experts, please help! :) ] If the two-byte bitfield is replaced by a two-byte struct (replace "short i:8" with "short i", etc.), the scheduler properly generates a dependency between the store and the load. For this case, a GEP is used instead of a bitcast:

On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > load-fadd-store chains to schedule. A store takes two cycles to > > clear > > its last pipeline stage. The fadd takes longer to compute its result > > (say 5

Hi Bill, Which scheduler do you use? MI or SDNode one? In either case the problem is likely the same, but cause might be in a different place... The way I see it, you have an issue with the alias analyzer, not scheduler. When scheduling DAG is constructed, AA is checked for pairs of mem accessing objects, and if no potential interference is flagged by the AA the chain edge is _not_ inserted.

Andy, Thanks for reply. I was able to trace the problem to the MI DAG dep constructor. See this: SU(0): %vreg1<def> = COPY %vreg10<kill>; IntRegs:%vreg1,%vreg10 # preds left : 0 # succs left : 0 # rdefs left : 1 Latency : 1 Depth : 0 Height : 0 SU(1): %vreg10<def> = LDriw %vreg9<kill>, 0;

On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: > On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: > > > > On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: > > > > > Here's my "thought experiment" (from PR11589): I have a bunch of > > > load-fadd-store chains to schedule. A store takes two cycles to > > > clear > >

On Fri, 2012-09-21 at 11:34 -0500, William J. Schmidt wrote: > Hi Sergei, > > Thanks for the response! We just discovered there is likely a bug > happening during post-RA list scheduling. There's an invalid successor > index in the scheduling graph that is probably supposed to be the > missing arc. Starting to investigate further now. This is recorded in >

Hi Sergei, Thanks for the response! We just discovered there is likely a bug happening during post-RA list scheduling. There's an invalid successor index in the scheduling graph that is probably supposed to be the missing arc. Starting to investigate further now. This is recorded in http://llvm.org/bugs/show_bug.cgi?id=13891. Thanks, Bill On Fri, 2012-09-21 at 11:15 -0500, Sergei Larin

On Dec 20, 2011, at 10:29 AM, Hal Finkel wrote: > On Tue, 2011-12-20 at 10:35 -0600, Hal Finkel wrote: >> On Mon, 2011-12-19 at 23:20 -0800, Andrew Trick wrote: >>> >>> On Dec 19, 2011, at 10:53 PM, Hal Finkel wrote: >>> >>>> Here's my "thought experiment" (from PR11589): I have a bunch of >>>> load-fadd-store chains to

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

Hi. I rewrote the patch according to the comments. I adopted generating in-place code because it looks the quickest way. The point Eddie wanted to discuss is how to generate code and its ABI. i.e. in-place generating v.s. direct jump v.s. indirect function call Indirect function call doesn't make sense because ivt.S is compiled multi times. And it is up to pv instances to choose in-place

OK, finally found it. The AliasChain in ScheduleDAGInstrs::buildSchedGraph is not acting as a chain for loads and stores (the head of the chain is not being updated as they are encountered, so dependencies aren't being added solely on the basis of may-aliasing in some cases). Will test a patch. On Fri, 2012-09-21 at 13:04 -0500, William J. Schmidt wrote: > On Fri, 2012-09-21 at 11:34

The register coalescer treats virtual super register classes -- a sequential register range composed of multiple hardware registers -- as a register with sub registers. When making coalescing decisions it thinks that the virtual super reg interferes with sub reg instances, even though in reality they shouldn't conflict. That is, they are individual registers and would be better compared as

Hi Borja, > Without doing what i mentioned and letting LLVM expand all operations wider > than 8 bits as you asked, the code produced is excellent supposing that many > of the moves there should be 16 bit moves reducing code size and right > register allocation, also something important for me is that the code is > better than gcc's. When i say right reg allocation it doesnt

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested

Jeff thanks for those suggestions, that's exactly what i would like to do, however i dont know how to do it with my current knowledge :\ As far as i understand patterns only take one instruction as an input (while the pattern you wrote before takes two) and also, i dont know how to handle register copying (COPY) in the .td file because they're handled in a different way to the rest of

Hi there, I am currently trying to create an LLVM Backend for a RISC architecture and running into problems with setCC and brcond. First a few explanations: The architecture doesn't have a dedicated flag register, but seven 1-bit-wide so called "condition registers", c0-c6, which can be set by e.g. a compare instruction: > cmp ne, c0, r1, 123 It also supports conditional

On May 31, 2013, at 4:07 PM, Joe Matarazzo <joe.matarazzo at gmail.com> wrote: > The register coalescer treats virtual super register classes -- a sequential register range composed of multiple hardware registers -- as a register with sub registers. When making coalescing decisions it thinks that the virtual super reg interferes with sub reg instances, even though in reality they

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>,