Re: [Sbcl-devel] [Sbcl-help] "Interesting" compiler warning in optimizing functions member, find, etc

[Nikodemus S. <nik...@ra...>]

On 1/16/08, Christophe Rhodes <cs...@ca...> wrote:

> Please, no.  NOTINLINE has the intuitive meaning of "this function
> will actually be called"; compiler macros are not expanded, and I
> think the same should be the case for deftransforms.

For future reference:

[15:03]  <nikodemus> Xof: i can buy the notinline for deftransforms
[15:04]  <nikodemus> but i assume you're not saying inline definitions
should trump deftransforms?
[15:06]  <Krystof> I think probably I would prefer inlines and
deftransforms to be mutually exclusive
[15:06]  <nikodemus> can have one, but not both?
[15:08]  <Krystof> but working out the details of that mechanism isn't
necessarily clear
[15:09]  <Krystof> so I think treating the inline expansion as a
transform to be applied when (a) other transforms haven't fired and
(b) space is not at a premium is OK
[15:09]  <nikodemus> right
[15:10]  <nikodemus> (i've for a while now wanted to do something to
deftransforms, so that their semantics would be independent of the
order of definition, but that is unrelated)
[15:14]  <nikodemus> oh bugger, this is not going to be trivial
[15:16]  <jsnell> you can't know when doing the inline transformation
that other transforms wouldn't be applicable after type propagation
[15:16]  <nikodemus> exactly
[15:20]  <nikodemus> so the zeroeth approximation is to remove inline
declarations from functions that have unconditional transforms

Cheers,

 -- Nikodemus