search for: computeissuewidth

Hi, Can someone tell me if my understanding is right in that post-RA scheduler currently assumes no limits on a pipeline's issue width? If so, is it by design or just overlooked? I have a case for, say, 1-issue pipeline when certain pipeline resource becomes occupied a few clocks after instruction start, but hazard evaluation is done incorrectly as scheduler advances clock not for every

...ying current LLVM sources. Otherwise, I have a (trivial) >> patch for it. >> >> BR >> >> m > > > Hi Max, > > The target's processor itinerary is expressive enough to enforce issue width. See ARMScheduleXX.td. Several months ago, I added ARMSubTarget::computeIssueWidth() so clients could query issue width without modeling the complete reservation table (via ScoreboardHazardRecognizer). This function may or may not work with your itinerary--you may need to write your own. I did consider adding a separate issue width field to the target description for targets that...

...wide machine can be described with N units, regardless of how deep the > pipeline is. > > Furthermore if you only need to model issue width, then you don't even need > to describe the pipeline at all. You only need to set the > InstrItineraryData::IssueWidth field. ARMSubtarget::computeIssueWidth does > this by assuming something about the convention of ARM itineraries. But you > could simply embed the issue width constants for your subtargets within the > target initialization code (in place of computeIssueWidth). I never bothered > to add tablegen support for an IssueWidth fie...