brian@uw-june.UUCP (Brian Bershad) (08/23/87)
I can understand the motivation (if it loops, it takes a while, so why bother with inline expanding), but the restriction seems arbitrary. Consider a spinlock for example: in the normal case, it returns immediately. Only rarely will the lock be held and will spinning be required. If it is an arbitrary restriction, what breaks if I take out the check for looping in dcl3.c? -- brian@june.cs.washington.edu Brian Bershad {ihnp4,decvax,ucbvax}!uw-beaver!uw-june!brian Dept. of Computer Science, FR-35 University of Washington Seattle, WA 98195
jss@hector..UUCP (Jerry Schwarz) (08/24/87)
In article <3004@uw-june.UUCP> brian@uw-june.UUCP (Brian Bershad) writes: >I can understand the motivation (if it loops, it takes a while, so >why bother with inline expanding), but the restriction seems arbitrary. > The limitation is a implementation limitation, not a philisophical one. Since cfront uses C as an intermediate language, in order to "inline" a function it must create an equivalent C expression. No C expressions (except function calls) contain loops. There are other circumstances in which cfront can't find an equivalent expression and generates a function call even when the function is declared "inline". In doubtful cases (and most are) I always examine the -F output of critical functions to be sure that inlining has been successful. Sometimes it is neccessary to change the body of the function declared inline to get good code. Jerry Schwarz