On 1/16/08, Kai-Florian Richter <richter@...> wrote:
> Is this expected behavior? Am I doing something obviously stupid that I
> don't see here?
No and no. Taking a _really_ quick look at this, it seems that MEMBER
is getting inlined there, instead of being transformed into %MEMBER-TEST.
(The operative declarations are (SPEED 2) (SPACE 0).)
What is our policy re transforms and inlining? I would have thought that
DEFTRANSFORMS should be preferred to inlining, and that they should fire
regardless of any NOTINLINE declarations -- which doesn't seem to be the
"Nikodemus Siivola" <nikodemus@...> writes:
> and that they [DEFTRANSFORMS] should fire regardless of any
> NOTINLINE declarations
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.
On 1/16/08, Christophe Rhodes <csr21@...> 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
[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