[llvm-commits] [PATCH] 64 functional units

Andrew Trick atrick at apple.com
Tue Jun 19 12:33:10 PDT 2012


On Jun 19, 2012, at 11:48 AM, Evan Cheng <evan.cheng at apple.com> wrote:

> Are you sure this is the right way to go? That's a lot of functional units and this change is probably increasing LLVM's memory foot print.
> 
> The InstrStage data structure is already poorly packed even before this change:
>  unsigned Cycles_;  ///< Length of stage in machine cycles
>  unsigned Units_;   ///< Choice of functional units
>  int NextCycles_;   ///< Number of machine cycles to next stage
>  ReservationKinds Kind_; ///< Kind of the FU reservation
> 
> We probably want to reduce the size of Cycles_ and NextCycles_ down to i16. This change is not helping. :-(

> On Jun 18, 2012, at 7:34 PM, Hal Finkel wrote:
>>> On Jun 13, 2012, at 7:04 AM, Hal Finkel wrote:
>>> 
>>>> Please review the attached patch which changes the datatype used to
>>>> hold the function-units bitmask from unsigned to uint64_t. In order
>>>> to describe some of the recent PowerPC chips (with all of their
>>>> relevant multi-stage pipelines), I need more than 32 FUs.

Hi Hal,

To address Evan's concerns I suggest...

1) Explain why you really want to model more then 32 FUs in these cores. The InstrStage descriptions are only needed for pipeline resources that are guaranteed to generate a stall/pipeline bubble when a conflict is present in the static schedule. Can you show that modeling all of the types of FuncUnits actually improves performance? Just doing this for "completeness" is not a great justification, since the ones that aren't included in the bit mask can be commented. Also, sometimes using one funcunit implies another, so they can share an itinerary unit.

FYI: I'm planning to introduce a new type of of Resource in the itinerary that the scheduler can try to avoid oversubscribing without modeling them with a reservation table. i.e. they don't take a bit in the bit mask. But this is really for OOO cores and may not be relevant.

2) Measure this increase in itinerary size. Can you report the increase in the size of the ARM tables?

3) Measure scheduling time. Is there any noticeable impact on either SD or PostRA scheduling in ARM?

This shouldn't be too hard since you should be building ARM target anyway and you don't need to run the generated code. But if you need help let me know.

Thanks,
Andy



More information about the llvm-commits mailing list