[LLVMdev] Question about per-operand machine model

[jingu]

Hi Andy,

I am trying to schedule and packetize instructions for VLIW at post-RA
stage or final codegen stage, where code transformations are not allowed
any more, because hardware can not resolve resource conflict. There is a
simple example as following:

ADD dest_reg1, src_reg1, src_reg2 (functional unit : ALU)
STORE dest_reg2, mem (functional unit: LOAD_STORE)

These instructions can be genally packetized together because there is
no dependency among operands and they use different functional unit. But
we have one more restricton. The restriction is that some of
instructions can not access to same register file at the same cycle. In
other words, if 'src_reg1' of ADD instruction uses register file 'A' and
'dest_reg2' of STORE instruction uses same register file at the same
cycle, it causes resource conflict and can not be executed on same
cycle. This restriction depends on instruction type. I tried to consider
each register file as a resource unit which is consumed by each operand.
While scheduling instructions per cycle, used register file is recorded
on state per cycle to check the conflict. In our heristic, it depends on
operand's latency to record this resource on specific cycle's state. so
I have tried to find a way to get latency and resource with each
operand. If it is not possible to support this feature with per-operand
resource model, as you suggested, I will try to make our own state
machine or other scheduling constraint logic. I am newbee with
scheduler. If you have any kinds of comment or feel something worng,
please let me know. It will be really helpful.

Thanks for your kind response,
JinGu Kang

On 2014-02-20 오전 2:27, Andrew Trick wrote:
> Hi JinGu,
>
> We currently have the ResourceCycles list to indicate the number of cpu cycles during which a resource is reserved. We could simply add a ResourceDelay with similar grammar. The MachineScheduler could be taught to keep track of the first and last time that a resource is reserved.
>
> Note that the MachineScheduler will work with the instruction itineraries if you choose to implement them. That’s the only way to get a full reservation table without customizing the scheduler. You can plugin your own state machine or other scheduling constraint logic. You may want to do this if you have very complicated constraints.
>
> Can you provide an example of the most complicated instruction resources that you need to model?
>
> -Andy
>
> On Feb 19, 2014, at 4:57 AM, JinGu Kang <jingu at codeplay.com> wrote:
>
>> Hi Andy,
>>
>> I am sorry to misunderstand 'ReadAdvance' code. In order to support
>> resource per operand, I feel we need more table and function. If
>> possbile, I would like to listen to your opinion whether this feature is
>> useful or not. As I mentioned on previous e-mail, it will be useful to
>> access the latency and the resource per operand while checking resource
>> conflict per cycle.
>>
>> Thanks,
>> JinGu Kang
>>
>> On 18/02/14 23:09, jingu wrote:
>>>> Resources and latency are not tied. An instruction is mapped to a
>>>> scheduling class. A scheduling class is mapped to a set of resources
>>>> and a per-operand list of latencies.
>>> Thanks for your kind explanation.
>>>
>>> Our heuristic algorithm have needed the latency and the resource per
>>> operand to check resource conflicts per cycle. In order to support
>>> this with LLVM, I expected a per-operand list of resources like
>>> latencies with a scheduling class.
>>>
>>> Can I ask you something to modify on tablegen? I think that the
>>> 'WriteResourceID' field of 'MCWriteLatencyEntry' is for identifying
>>> the WriteResources of each defintion as commented on code. As you
>>> know, tablegen sets the 'WriteResourceID' field of
>>> 'MCWriteLatencyEntry' with 'WriteID' when the 'Write' of defition is
>>> referenced by a 'ReadAdvance'. If we always set this field with
>>> 'WriteID', it causes problem? I can see that 'ReadAdvance' only uses
>>> the 'WriteResourceID' field of 'MCWriteLatencyEntry' in
>>> 'computeOperandLatency' function. I think the pair of latency and
>>> write resource for defintion will be useful to check conflicts of
>>> resources. As reference, I have attached simple patch.
>>>
>>> Thanks,
>>> JinGu Kang
>>>