[LLVMdev] ARM issue: Trying to add an operand to a machine instr that is already done!

Karel Gardas karel.gardas at centrum.cz
Tue Aug 30 13:15:33 PDT 2011


Hi,

as promised I'm reporting back. So advice to update really helped and 
GHC/LLVM/ARM is working well again for me.

Thanks a lot!
Karel

On 08/29/11 11:40 PM, Karel Gardas wrote:
>
> Hi Jim and Eric!
>
> thanks a lot for your fantastically fast reply. I'm going to update and
> will report tomorrow when all the building is done.
>
> Thanks!
> Karel
>
> On 08/29/11 11:36 PM, Jim Grosbach wrote:
>> Hi Karel,
>>
>> Mind trying again with current top of tree? Owen's fixed a few things
>> today that were manifesting with that error.
>>
>> -Jim
>>
>> On Aug 29, 2011, at 2:33 PM, Karel Gardas wrote:
>>
>>> Hello,
>>>
>>> I've compiled today's LLVM on ARM/Linux machine and attempted to use
>>> our GHC/ARM port (which is using LLVM as a backend for generating
>>> machine code) with it but I've failed in compiling GHC alone as LLVM
>>> fails on me with following message:
>>>
>>> llc:
>>> /export/home/karel/vcs/llvm-ghc-arm/lib/CodeGen/MachineInstr.cpp:612:
>>> void llvm::MachineInstr::addOperand(const llvm::MachineOperand&):
>>> Assertion `(isImpReg || !OperandsComplete())&& "Trying to add an
>>> operand to a machine instr that is already done!"' failed.
>>> Stack dump:
>>> 0. Program arguments: llc -O3 -relocation-model=static
>>> /tmp/ghc12607_0/ghc12607_0.bc -o /tmp/ghc12607_0/ghc12607_0.lm_s
>>> -mattr=+v7,+vfp3
>>> 1. Running pass 'Function Pass Manager' on module
>>> '/tmp/ghc12607_0/ghc12607_0.bc'.
>>> 2. Running pass 'ARM load / store optimization pass' on function
>>> '@s51E_info'
>>> Aborted
>>>
>>> FYI: Stephen Blackheath enhanced LLVM to support custom GHC calling
>>> convention on ARM and I've added support for floating point regs to
>>> his patch. Current version is attached for your reference. I'm
>>> writing this since GHC/ARM is working well with LLVM from 2011-07-12
>>> with this patch applied but it's not working with today's LLVM. I'm
>>> curious if this failure is caused by our patch (or some omission in
>>> it) or if this is issue in LLVM itself.
>>>
>>> Thanks for any idea where to start looking to fix that!
>>> Karel
>>> <ghc_llvm.patch>_______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>




More information about the llvm-dev mailing list