This did not seem to work, any other ideas? Thanks, -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Thursday, January 15, 2009 2:26 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Hitting assertion, unsure why Don't generate debug info at this time (you can use "opt -strip-debug")? :-) Otherwise, I'm not sure. -bw On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:> Is there any known method/hack of bypassing this? > > Thanks, > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Bill Wendling > Sent: Thursday, January 15, 2009 2:07 PM > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Hitting assertion, unsure why > > On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah<Micah.Villmow at amd.com>> wrote: >> I am hitting this assertion: >> >> assert(I != VRBaseMap.end() && "Node emitted out of order - late"); >> >> I am not sure why this assertion is being triggered or what I changed > that >> is causing it. >> >> This is asserting when SDValue is FrameIndexSDNode 1. >> >> I don't have any code that modified frameindices until my overloaded >> RegisterInfo function. >> >> I've attached the bc file. If I generate an unoptimized bc file then > there >> is no issue, only when I turn optimizations on do I hit this problem. >> > I got this too. It's related to debug information being in flux right > now. I believe that Devang is working on a fix for this right now. > > -bw > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Other than not using debugging ('-g' and the like), not really. :-( I
think that Devang is actively working on fixing this, though. It might
not be too much longer.
-bw
On Thu, Jan 15, 2009 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:> This did not seem to work, any other ideas?
>
> Thanks,
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Bill Wendling
> Sent: Thursday, January 15, 2009 2:26 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>
> Don't generate debug info at this time (you can use "opt
> -strip-debug")? :-) Otherwise, I'm not sure.
>
> -bw
>
> On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at
amd.com>
> wrote:
>> Is there any known method/hack of bypassing this?
>>
>> Thanks,
>>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
>> On Behalf Of Bill Wendling
>> Sent: Thursday, January 15, 2009 2:07 PM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>>
>> On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah
> <Micah.Villmow at amd.com>
>> wrote:
>>> I am hitting this assertion:
>>>
>>> assert(I != VRBaseMap.end() && "Node emitted out of
order - late");
>>>
>>> I am not sure why this assertion is being triggered or what I
changed
>> that
>>> is causing it.
>>>
>>> This is asserting when SDValue is FrameIndexSDNode 1.
>>>
>>> I don't have any code that modified frameindices until my
overloaded
>>> RegisterInfo function.
>>>
>>> I've attached the bc file. If I generate an unoptimized bc file
then
>> there
>>> is no issue, only when I turn optimizations on do I hit this
problem.
>>>
>> I got this too. It's related to debug information being in flux
right
>> now. I believe that Devang is working on a fix for this right now.
>>
>> -bw
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
Ok, I've had time to track this down a little bit more and I seem to
have found another case where it fails. This is occurring during
Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem seems
to be that somehow the CopyToReg part of the switch statement in
ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is
especially problematic because the code is either expecting a
VirtualRegister or a RegisterSDNode in this location. I've checked all
locations where I use the DAG.getCopyToReg function and none of them
pass in a frameindex. I explcitily check that I have a register before
passing in the value to Register number to CopyToReg, so this leads me
to believe that it is being generated somehow by LLVM.
In the case I sent earlier in this thread it only occurs when I turn
optimizations on, but the new case I hit with optimizations off but
through a different method.
I've tried the strip-debug method and that doesn't seem to help, any
other ideas or tips where I can look to further debug this issue would
be very helpful.
Thanks,
Micah
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bill Wendling
Sent: Thursday, January 15, 2009 3:32 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Hitting assertion, unsure why
Other than not using debugging ('-g' and the like), not really. :-( I
think that Devang is actively working on fixing this, though. It might
not be too much longer.
-bw
On Thu, Jan 15, 2009 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:> This did not seem to work, any other ideas?
>
> Thanks,
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Bill Wendling
> Sent: Thursday, January 15, 2009 2:26 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>
> Don't generate debug info at this time (you can use "opt
> -strip-debug")? :-) Otherwise, I'm not sure.
>
> -bw
>
> On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah
<Micah.Villmow at amd.com>> wrote:
>> Is there any known method/hack of bypassing this?
>>
>> Thanks,
>>
>> -----Original Message-----
>> From: llvmdev-bounces at cs.uiuc.edu
[mailto:llvmdev-bounces at cs.uiuc.edu]>> On Behalf Of Bill Wendling
>> Sent: Thursday, January 15, 2009 2:07 PM
>> To: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Hitting assertion, unsure why
>>
>> On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah
> <Micah.Villmow at amd.com>
>> wrote:
>>> I am hitting this assertion:
>>>
>>> assert(I != VRBaseMap.end() && "Node emitted out of
order - late");
>>>
>>> I am not sure why this assertion is being triggered or what I
changed>> that
>>> is causing it.
>>>
>>> This is asserting when SDValue is FrameIndexSDNode 1.
>>>
>>> I don't have any code that modified frameindices until my
overloaded
>>> RegisterInfo function.
>>>
>>> I've attached the bc file. If I generate an unoptimized bc file
then
>> there
>>> is no issue, only when I turn optimizations on do I hit this
problem.>>>
>> I got this too. It's related to debug information being in flux
right
>> now. I believe that Devang is working on a fix for this right now.
>>
>> -bw
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StandardLinkConstraintSet.bc
Type: application/octet-stream
Size: 644 bytes
Desc: StandardLinkConstraintSet.bc
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090127/3c8b4998/attachment.obj>