Displaying 7 results from an estimated 7 matches for "load_store".
2012 Jun 11
2
[LLVMdev] Why always abort in verifyFunction?
...tion*
verifyModule will print to stderr and return true
*ReturnStatusAction*
verifyModule will just return true
But it still abort when I pass PrintMessageAction/ReturnStatusAction
to function.
Log:
Basic Block in function 'jitmain' does not have terminator!
label %load_store
LLVM ERROR: Broken module, no Basic Block terminator!
Is there something wrong?
Best regards,
-myesis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120611/058f832b/attachment.html>
2012 Jun 11
0
[LLVMdev] Why always abort in verifyFunction?
...turn true
> *ReturnStatusAction*
>
> verifyModule will just return true
>
> But it still abort when I pass
> PrintMessageAction/ReturnStatusAction to function.
>
> Log:
> Basic Block in function 'jitmain' does not have terminator!
> label %load_store
> LLVM ERROR: Broken module, no Basic Block terminator!
>
>
> Is there something wrong?
>
>
> Best regards,
> -myesis
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs....
2014 Feb 19
2
[LLVMdev] Question about per-operand machine model
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.
2012 Jun 12
2
[LLVMdev] Why always abort in verifyFunction?
...>>
>> verifyModule will just return true
>>
>> But it still abort when I pass
>> PrintMessageAction/ReturnStatusAction to function.
>>
>> Log:
>> Basic Block in function 'jitmain' does not have terminator!
>> label %load_store
>> LLVM ERROR: Broken module, no Basic Block terminator!
>>
>>
>> Is there something wrong?
>>
>>
>> Best regards,
>> -myesis
>>
>> _______________________________________________
>> LLVM Developers mailing list
>>...
2014 Feb 28
2
[LLVMdev] Question about per-operand machine model
...; 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...
2014 Mar 03
2
[LLVMdev] Question about per-operand machine model
...de 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...
2014 Mar 04
2
[LLVMdev] Question about per-operand machine model
...gt;>>> 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
>>...