Hi Evan, thanks for your response. On Mon, 19 Jan 2009, Evan Cheng wrote:>> For example, code which looks like that: >> >> load 0x1234, reg1 >> noop >> noop >> add reg1, 1 >> load 0x1236, reg2 >> >> can be safely transformed to: >> >> load 0x1234, reg1 >> load 0x1236, reg2 >> noop >> add reg1, 1 >>> The register allocator doesn't reschedule code. It can coalesce > copies, commute instructions, and do re-materialization, etc.Sorry for using the wrong vocabulary.> It's not clear what kind of problems you are running it.When we limited our target to have only 3 registers available the code post-hazard-recognized looks like that: load 0x1234, reg1024 load 0x1236, reg1025 load 0x1238, reg1026 load 0x1240, reg1027 add reg1024, 1 add reg1025, 2 add reg1026, 3 add reg1027, 4 after register allocation: load 0x1234, reg1 load 0x1236, reg2 load 0x1238, reg3 add reg1, 1 add reg2, 2 add reg3, 3 store reg1, 0x1234 load 0x1240, reg1 add reg1, 4 Which won't work on our platform. It is missing 2 NOOPs after the last load. The DelaySlotFiller could add the two NOOPs, but that would be less optimal than doing the store-load before the add of reg2 and reg3 (no NOOP in that case).>> And more generally: Is the hazardRecognizer the right and only way to >> solve our NOOP-minimizing problem? > > Perhaps you want to do this after register allocation is done. Dan is > developing the post-allocation scheduler. You can try it out.Interesting. Can it already be found SVN? I will search the mail archive later, if not. regards, Patrick.
On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote:> > >>> And more generally: Is the hazardRecognizer the right and only way >>> to >>> solve our NOOP-minimizing problem? >> >> Perhaps you want to do this after register allocation is done. Dan is >> developing the post-allocation scheduler. You can try it out. > > Interesting. Can it already be found SVN? I will search the mail > archive > later, if not.Yes, it is in SVN. It's new, and so far it's only being used in limited ways, and not anything like your specific problem. We don't currently have any targets in-tree that require no-ops, so it may not address all your needs out of the box, but patches are welcome :-). Dan
On Monday 19 January 2009 16:42, Dan Gohman wrote:> >> Perhaps you want to do this after register allocation is done. Dan is > >> developing the post-allocation scheduler. You can try it out. > > > > Interesting. Can it already be found SVN? I will search the mail > > archive > > later, if not. > > Yes, it is in SVN. It's new, and so far it's only being used in limited > ways, and not anything like your specific problem. We don't currently > have any targets in-tree that require no-ops, so it may not address all > your needs out of the box, but patches are welcome :-).Dan, how does the scheduler handle memory dependence? I'm working on something that requires memory dependence information for MachineInstructions. -Dave
Dan: CellSPU could clearly benefit from the post-RA scheduler. In fact, we were thinking about writing a machine pass of our own. One thing that does "disturb" me is that both HazardRecognizer and post-RA sched assume there's only one kind of NOP. For Cell, there are two, depending upon the pipeline being filled. Pipe 0 takes "ENOP" whereas Pipe 1 take "LNOP" (depends on the low order PC bits.) -scooter On Jan 19, 2009, at 2:42 PM, Dan Gohman wrote:> > On Jan 19, 2009, at 11:01 AM, Patrick Boettcher wrote: >> >> >>>> And more generally: Is the hazardRecognizer the right and only way >>>> to >>>> solve our NOOP-minimizing problem? >>> >>> Perhaps you want to do this after register allocation is done. >>> Dan is >>> developing the post-allocation scheduler. You can try it out. >> >> Interesting. Can it already be found SVN? I will search the mail >> archive >> later, if not. > > Yes, it is in SVN. It's new, and so far it's only being used in > limited > ways, and not anything like your specific problem. We don't currently > have any targets in-tree that require no-ops, so it may not address > all > your needs out of the box, but patches are welcome :-). > > Dan > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev