From: Klaus F. <kla...@gm...> - 2003-09-26 21:11:55
Attachments:
lrange.patch
|
Hi all, i wrote a little patch to fix the liverange bug. With this patch the code from the bugreport compiles fine and the problem with gets.c is also fixed. Perhaps somone could have a look at this. regards Klaus Flittner |
From: Bernhard H. <ber...@be...> - 2003-09-29 13:23:37
|
> i wrote a little patch to fix the liverange bug. With this patch the > code from the bugreport compiles fine > and the problem with gets.c is also fixed. > Perhaps somone could have a look at this. Unfortunately bug #536787 isn't fixed by your patch, it seems to be a different LR problem. I'm unsure what to do. Comments? Bernhard |
From: Klaus F. <kla...@gm...> - 2003-09-29 18:55:50
Attachments:
lrange-new.patch
|
> > >>i wrote a little patch to fix the liverange bug. With this patch the >>code from the bugreport compiles fine >>and the problem with gets.c is also fixed. >>Perhaps somone could have a look at this. >> >> >Unfortunately bug #536787 isn't fixed by your patch, it seems to be a >different LR problem. > >I'm unsure what to do. Comments? > > I've looked at this problem again. In the first patch i did not consider the case of loops inside loops. This new patch fixes the LR problem from bug #536787 and #519583. Possibly also the other LR related bugs, but i didn't checked them. regards Klaus Flittner |
From: Klaus F. <kla...@gm...> - 2003-10-01 11:37:08
Attachments:
lrange-new.patch
|
Hello, in the last patch i forgot a little part from the old patch. Now the patch works and fixes the liverange problems from bug #519583, #536787, #660312 regards Klaus Flittner |
From: Bernhard H. <ber...@be...> - 2003-10-03 22:15:54
|
Hi Klaus! > in the last patch i forgot a little part from the old patch. > Now the patch works and fixes the liverange problems from bug > #519583, #536787, #660312 The patch looks great now! Many, many thanks for fixing this long standing bug! I did some tests, but not thoroughly. I hope for some feedback from the user :-) I took the liberty to fix the tab length (it's 8 in SDCC) and to reformat the source acc. the GNU coding standard. Bernhard |
From: Jesus Calvino-F. <Je...@ec...> - 2003-10-04 05:53:46
|
The bugs may be fixed, but so many sloc variables are generated now that there is not enough memory for my projects. In one case the use of internal data memory goes from 71 to 96 bytes, an unacceptable increment of 25 bytes! And that after making all static variables in vprintf.c volatile, otherwise the number of sloc variables is even worst. How comes a program with volatile variables uses less memory than the same one with static variables? Jesus At 12:15 AM 10/4/2003 +0200, you wrote: >Hi Klaus! > > > in the last patch i forgot a little part from the old patch. > > Now the patch works and fixes the liverange problems from bug > > #519583, #536787, #660312 >The patch looks great now! Many, many thanks for fixing this long standing >bug! I did some tests, but not thoroughly. I hope for some feedback from the >user :-) > >I took the liberty to fix the tab length (it's 8 in SDCC) and to reformat the >source acc. the GNU coding standard. > >Bernhard > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >sdcc-devel mailing list >sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-devel > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.515 / Virus Database: 313 - Release Date: 9/1/2003 |
From: Bernhard H. <ber...@be...> - 2003-10-04 08:16:37
|
> The bugs may be fixed, but so many sloc variables are generated now that > there is not enough memory for my projects. In one case the use of > internal data memory goes from 71 to 96 bytes, an unacceptable increment of > 25 bytes! And that after making all static variables in vprintf.c > volatile, otherwise the number of sloc variables is even worst. How comes > a program with volatile variables uses less memory than the same one with > static variables? Klaus, do you see a chance to fix this? Otherwise we would have to make your LR changes an option, e.g. by embracing them with getenv ("KLAUSLR"). Bernhard |
From: Klaus F. <kla...@gm...> - 2003-10-04 12:45:00
|
Bernhard Held schrieb: >>The bugs may be fixed, but so many sloc variables are generated now that >>there is not enough memory for my projects. In one case the use of >>internal data memory goes from 71 to 96 bytes, an unacceptable increment of >>25 bytes! And that after making all static variables in vprintf.c >>volatile, otherwise the number of sloc variables is even worst. How comes >>a program with volatile variables uses less memory than the same one with >>static variables? >> >> >Klaus, do you see a chance to fix this? Otherwise we would have to make your >LR changes an option, e.g. by embracing them with getenv ("KLAUSLR"). > > > There is a possibiliy to fix this, but not without a major change. At the moment the liverange of an iTemp is lasting form the first definition to the last usage (evtl. extended to the end of a loop). If we would save for every icode which itemps are alive instead of just the start and end of a liverange, then we could save probably some slocs again. for example: iTemp0 = something ... here iTemp0 is alive ... something = iTemp0 ... here iTemp0 is not used and the value stored in it is no more relevant ie. here the register assigned to iTemp0 could be used again. ... iTemp0 = ... To my patch: There is still a little typo in my patch: in file SDCCloop.c, function addLoopBlocks: in the last if clause i typed an 'i' where should be an 'j' if (!isinSet (ebbs[i]->partOfLoop, aloop)) should be if (!isinSet (ebbs[j]->partOfLoop, aloop)) this has no effect on the vprintf related bug, but the other bugs aren't fixed without this little change. Klaus |
From: Bernhard H. <ber...@be...> - 2003-10-05 19:23:01
|
> >Klaus, do you see a chance to fix this? Otherwise we would have to make > > your LR changes an option, e.g. by embracing them with getenv > > ("KLAUSLR"). > > There is a possibiliy to fix this, but not without a major change. > At the moment the liverange of an iTemp is lasting form the first > definition to the last usage (evtl. extended to the end of a loop). I guess, that the general extension to the end of a loop is the problem. I've restored the old default LR behaviour. Klaus' patches can be selected by defining the environment variable LRKLAUS: $ LRKLAUS=1 sdcc -S vprintf.c Bernhard |