[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


bwb@cs.unh.edu (Brent Benson) writes:

> rjz@chaos.cs.brandeis.edu ("Roland Zito-Wolf") writes:

> > 3. Given that (to my knowledge) the compiler gives no messages about
> > what has or has not been optimized and/or coded inline, or any
> > compilation statistics such as size of the resulting code,
> > subprimitive calls, etc, or as to which decls have been ignored or
> > utilized; and

> It's not very elegant, but Why not use DISASSEMBLE to have a look at
> the resulting code.

I am.  Certain things like INLINEing are easy to detect 
by a quick  look at the code; other things require a detailed
groveling over the code that I would rather avoid. In either case,
the process of getting the compiler to produce what i intended 
is basically trial-and-error, and given the number of options
(just consider all the places declarations might go, never mind their
content), mostly trial. A little help form the compiler would go a long way
to fix this, eg, "I didnt inline this call because.."

Anyway, some other specific questions (I'm in MACL 1.3, by the way):

1. certain "obvious" functions dont inline themselves (even if I ask):
  >=, SECOND

2. does INLINE actually do anything, except for accessor functions? the
  manual is indefinite on this. 

3. Is there a fast version of the POSITION function tailored to BIT VECTORS?

4. what type declarations (eg, (BIT-VECTOR *)? fixnum?) are likely to 
 produce optimized code?