From: Philipp K. K. <pk...@sp...> - 2017-04-06 21:44:05
|
One problem with SDCC is that it only goes through the source files item by item. This results in inefficiencies and bugs. Example: inline void f(void) { … } extern void f(void); Does not result in a definition of usable from other compilation units. This is a bug. SDCC behaves correctly, if the extern declaration is before the inline definition. Example: static inline void f(void) { … } Always results in a definition in the asm file, even when all uses are inlined. A similar situation appears for static functions and variables that are not used (future optimizations might be able to optimize out all uses of a static variable). What should we do about it? I currently see two options: 1) Do a first pass over the whole source file to find all uses before even emitting any code. 2) Do not emit anything for the inline and static stuff. Instead keep the AST around somewhere, in case it is needed later (once we've completed the normal pass through the source file). Philipp P.S.: A linker that removes unreferenced functions and other symbols would help with the inefficiency issues mentioned (and some more). But I don't see how it would help with the bug. P.P.S.: I stumbled upon this again, when looking for a fix for bug #2591. The obvious fix would be to not emit the params for inline functions. But that would become another problem when fixing the bug mentioned above. |
From: 陳韋任 <che...@g2...> - 2017-04-07 23:34:31
|
> > I currently see two options: > > 1) Do a first pass over the whole source file to find all uses before > even emitting any code. > 2) Do not emit anything for the inline and static stuff. Instead keep > the AST around somewhere, in case it is needed later (once we've > completed the normal pass through the source file). > What the pros and cons about above options, like how easily be implemented in current code base? Personally, I prefer keeping AST around until we done everything. Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage: https://people.cs.nctu.edu.tw/~chenwj |
From: Philipp K. K. <pk...@sp...> - 2017-04-10 12:18:55
|
Am 08.04.2017 um 01:12 schrieb 陳韋任: > I currently see two options: > > 1) Do a first pass over the whole source file to find all uses before > even emitting any code. > 2) Do not emit anything for the inline and static stuff. Instead keep > the AST around somewhere, in case it is needed later (once we've > completed the normal pass through the source file). > > > What the pros and cons about above options, like how easily be implemented > in current code base? Both would mostly affect frontend and glue stuff; I'm not an expert on either, but I guess them to be similar in terms of implementtion effort. Maybe 2) is a little bit easier. A small advantage of 1) might be that in the final pass that does emit code, we process stuff in the same order as the are in the source file. Thus, asm code will better correspond to C source, and error messages tend to be more in order with the C source. Also 1) Might later generalize to make the first pass a analysis pass for to ther purposes, too (useful for interprocedural optimizations¹). We'd have to decide if the first pass should be AST generation only or go further. Philipp ¹ Currently interprocedural optimizations in SDCC only consider information about functions defined before the current function, since there is no information about further ones. With 1) We might be able to relatively easily obtain some information about other functions from the same source file, too. I don't see a way to do that with 2). |
From: Maarten B. <sou...@ds...> - 2017-05-14 14:34:54
|
> Am 08.04.2017 um 01:12 schrieb é³éä»»: >> I currently see two options: >> >> 1) Do a first pass over the whole source file to find all uses >> before >> even emitting any code. >> 2) Do not emit anything for the inline and static stuff. Instead >> keep >> the AST around somewhere, in case it is needed later (once we've >> completed the normal pass through the source file). >> >> >> âWhat the pros and cons about above options, like how easily be >> implemented >> in current code base? > > Both would mostly affect frontend and glue stuff; I'm not an expert on > either, but I guess them to be similar in terms of implementtion effort. > Maybe 2) is a little bit easier. > > A small advantage of 1) might be that in the final pass that does emit > code, we process stuff in the same order as the are in the source file. > Thus, asm code will better correspond to C source, and error messages > tend to be more in order with the C source. Also 1) Might later > generalize to make the first pass a analysis pass for to ther purposes, > too (useful for interprocedural optimizations¹). > We'd have to decide if the first pass should be AST generation only or > go further. > > Philipp > > ¹ Currently interprocedural optimizations in SDCC only consider > information about functions defined before the current function, since > there is no information about further ones. With 1) We might be able to > relatively easily obtain some information about other functions from the > same source file, too. I don't see a way to do that with 2). I kind of missed this discussion. I always had 2) as a possible solution in my mind, but I can see that 1) could have additional benefits. Maybe this should be turned into a feature request? Maarten |