RE: [sdcc-devel] Problems with updateSpillLocation

[Sandeep D. <sa...@dd...>]

Michael,

This is very similar to the problem pointer post & pre
increment problem. Will take a shot at fixing it this weekend.

Sorry folks... just have been soooo caught up at work ...
code generation for DSPs is really painful .....


Sandeep

> -----Original Message-----
> From: sdc...@li...
> [mailto:sdc...@li...]On Behalf Of 
> Michael Hope
> Sent: Wednesday, August 08, 2001 10:10 PM
> To: sdc...@li...
> Subject: [sdcc-devel] Problems with updateSpillLocation
> 
> 
> Evening all.  I'm having trouble with updateSpillLocation joining two
> seperate variables.  I've finally turned on loop induction for the z80
> port, and by default it breaks the dhrystone test.  What 
> happens is that
> the local variables Run_Index and Int_2_Loc get merged into 
> the same spill
> location as at one point Int_2_Loc is assigned the value of Run_Index.
> 
> Specifically,
> Due to the loop induction code, Run_Index gets copied into an iTemp.
> Int_2_Loc is later assigned the value of that iTemp.  
> Int_2_Loc is later
> modified by other code.  During the second stage cse the iTemp doesn't
> have a spill loc, but Int_2_Loc does, so the iTemp is placed 
> into the same
> spill loc.
> 
> No other ports see this due to the !IN_FARSPACE condition in
> updateSpillLocation as the z80 uses _near (16 bit) mode by default.
> 
> Help.  I don't understand the logic in updateSpillLocation, 
> especially the
> distinction between near and far spill locations when 
> joining.  For now
> I've put in a hack to disable these for the z80 port.
> 
> -- Michael
> 
> 
> _______________________________________________
> sdcc-devel mailing list
> sdc...@li...
> http://lists.sourceforge.net/lists/listinfo/sdcc-devel
> 
> 
>